Closed Bug 501045 Opened 15 years ago Closed 15 years ago

Clicking Growl New Mail Notification Results in "imap-message is not a registered protocol" error

Categories

(Thunderbird :: OS Integration, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0b4

People

(Reporter: ilan, Assigned: humph)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090628 Shredder/3.0b3pre)

On OSX when new mail arrives, clicking the growl notification brings up the Mail and News Groups window, with an error message "imap-message is not a registered protocol".  It should open the message the notification was about.

Reproducible: Always

Steps to Reproduce:
1. Receive a new e-mail message while Thunderbird does not have focus.
2. Click on the Growl notification.
3. Rather than displaying the new message, an error is displayed:  "imap-message is not a registered protocol".  The only option is to click ok.
Actual Results:  
An error is displayed:  "imap-message is not a registered protocol".  The only option is to click ok.

Expected Results:  
The received message or the related inbox should be displayed.

OS:  Mac OSX  10.5.7
Processor:  MacBook Pro 15" / MacBookPro2,2 - 2.33GHz Intel Core 2 Duo
Growl Version: 1.1.4
I'd like to confirm this, as I do encounter the same symptoms. I think this error popped up in an early June nightly build, I don't know exactly when however :(

Reproducible: Always

OS:  Mac OSX  10.5.7
Growl Version: 1.1.4
TB: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090617 Shredder/3.0b3pre
confirming on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090701 Shredder/3.0b3pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
This appears to have improved in recently nightly builds.  An error message is no longer displayed.  Instead it takes you to the appropriate inbox. It previously opened the message you were being notified about.  I'm unsure which result is the correct behavior.
Gary, fancy trying to find a regression window for this? I think it might help with sorting out the fix.
(In reply to comment #4)
> Gary, fancy trying to find a regression window for this? I think it might help
> with sorting out the fix.

Yup, working on it.
(In reply to comment #5)
> (In reply to comment #4)
> > Gary, fancy trying to find a regression window for this? I think it might help
> > with sorting out the fix.
> 
> Yup, working on it.

Works:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090612 Lightning/1.0pre Shredder/3.0b3pre

Fails:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090613 Lightning/1.0pre Shredder/3.0b3pre

http://hg.mozilla.org/comm-central/pushloghtml?fromchange=9c990709ec02&tochange=c2280881464b

Gloda mega-landing?
Version: unspecified → Trunk
Summary: Clicking Growl New Mail Notifaction Results in "imap-message is not a registered protocol" error → Clicking Growl New Mail Notification Results in "imap-message is not a registered protocol" error
Attached patch FixSplinter Review
Sid and I figured this out, and was due to a *-message uri.
Assignee: nobody → david.humphrey
Status: NEW → ASSIGNED
Attachment #391683 - Flags: review?(bugzilla)
Comment on attachment 391683 [details] [diff] [review]
Fix

Thanks for working this one out. r=Standard8
Attachment #391683 - Flags: review?(bugzilla) → review+
Attachment #391683 - Flags: superreview?(bienvenu)
Attachment #391683 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 391683 [details] [diff] [review]
Fix

we should have a service for this so that we don't have to create nsMessenger instances...
Yeah, would have been nice.  I'm currently the only caller who does this (cpp).
Keywords: checkin-needed
As it turns out, this doesn't quite work for SeaMonkey. I'm trying to come up with something for that at the moment.
Keywords: checkin-needed
Attached patch Revert for SMSplinter Review
Additional patch reverting what SM does and using an ifdef - sid tells me that in bug 507593 we're going to be redoing how Thunderbird acts when you click on the alert and so some of this will be changed again anyway. So for now ifdef seems like the simplest option (alternately SM could pick up the changes which mean accepting msgHdrs).
Attachment #391847 - Flags: superreview?(neil)
Attachment #391847 - Flags: review?(neil)
Comment on attachment 391847 [details] [diff] [review]
Revert for SM

So basically a combined diff would look like this, right?

>+        // SeaMonkey only supports message uris, whereas Thunderbird only
>+        // supports message headers. This should be simplified/removed when
>+        // bug 507593 is implemented.
>+#ifdef MOZ_SUITE
>         nsCOMPtr<nsIDOMWindow> newWindow;
>         wwatch->OpenWindow(0, "chrome://messenger/content/messageWindow.xul",
>                            "_blank", "all,chrome,dialog=no,status,toolbar", msgUri,
>                            getter_AddRefs(newWindow));
>+#else
>+        nsCOMPtr<nsIMessenger> messenger(do_CreateInstance(NS_MESSENGER_CONTRACTID, &rv));
>+        if (NS_FAILED(rv))
>+          return;
...
>+                             "_blank", "all,chrome,dialog=no,status,toolbar", msgHdr,
>+                             getter_AddRefs(newWindow));
>+        }
>+#endif
Attachment #391847 - Flags: superreview?(neil)
Attachment #391847 - Flags: superreview+
Attachment #391847 - Flags: review?(neil)
Attachment #391847 - Flags: review+
(In reply to comment #13)
> (From update of attachment 391847 [details] [diff] [review])
> So basically a combined diff would look like this, right?

Correct.

Checked in as one combined changeset:

http://hg.mozilla.org/comm-central/rev/77e413670fd0

Probably should have a test somewhere in litmus for this.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: blocking-thunderbird3? → in-litmus?
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b4
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090802 Shredder/3.0b4pre
Status: RESOLVED → VERIFIED
It works in latest trunk (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090806 Shredder/3.1a1pre) but produces unexpected behavior -- instead of showing the main Thunderbird window with the message selected it opens a new windows with the message. This is a change from the behavior of 3.0b2 and earlier.
> instead of showing the main Thunderbird window with the message
> selected it opens a new windows with the message. This is a change from the
> behavior of 3.0b2 and earlier.

I wrote both versions and I've never seen it open in the main window.  It always opened in a new window.  You might be thinking of what happens when you click a Growl alert for multiple messages in the same folder vs. a single message.  This does select the folder and highlight the first message.  Single messages are opened in a new window.

We should get it working in a new tab, but that wants another bug and some of Sid's magic.
I assure you the current behavior is different from what I observed in beta 2. In the beta, clicking the growl notification for a *single message* opened the main Thunderbird window.
(In reply to comment #21)
> I assure you the current behavior is different from what I observed in beta 2.
> In the beta, clicking the growl notification for a *single message* opened the
> main Thunderbird window.

Whether beta 2 did or not, please raise a separate bug for that otherwise it could get lost here.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: