Closed Bug 216308 Opened 21 years ago Closed 5 years ago

message box repeatedly asking for 'subscribe to <foldername>?' when forwarding a message stored in an IMAP folder

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr6870+ fixed, thunderbird70 verified, thunderbird71 verified)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 71.0
Tracking Flags:
Tracking Status
thunderbird_esr68 70+ fixed
thunderbird70 --- verified
thunderbird71 --- verified

People

(Reporter: bugzilla.mozilla.org, Assigned: gds)

References

Details

Attachments

(4 files, 1 obsolete file)

Cropped screenshot of dialog box in question
6.77 KB, image/gif
Details
Source for the example email
13.96 KB, text/plain
Details
SameErrorAfterTBUpdate-45.7.0
27.14 KB, image/jpeg
Details
subscribe-fix.diff
2.40 KB, patch
jorgk-bmo
: review+
jorgk-bmo
: approval-comm-beta+
jorgk-bmo
: approval-comm-esr68+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+ Email Agent: Mozilla Thunderbird 0.2a (20030813) nightly build -- also occurs in previous versions, including the Thunderbird 0.1 release. Also tested was Mozilla Thunderbird 0.2a (20030807) nightly build. When forwarding a message from an IMAP server in a nested folder, I receive a dialog box asking: "Would you like to subscribe to ~dusty/Clients^^Some Client Name?" with "OK" and "Cancel" buttons and a title of "Confirm". If you click "Cancel", it continues to ask again. The IMAP folder that this message is stored in is in the structure of "IMAP Server -> user: dusty -> Clients -> Some Client Name" which is actually stored at "/home/dusty/Clients/Some\ Client\ Name" on the Linux filesystem. It seems the error has something to do with the image attachments. When the image attachments are stripped from the email, the error does not occur. It looks like the number of times it asks the question ("cancel" -> reopen dialog) is based on the number of attached and/or referenced images in the email message. This error does not occur when the forwarding option is set to "as attachment". Reproducible: Always Steps to Reproduce: 1. Use an IMAP incoming mail server account. 2. Set forwarding option to "inline" in the "Options > Composition > Forwarding and Replying to Messages" area. 3. Select (single-click) or open (double-click) the email message in the email list. 4. Click the "Forward" button in the toolbar of the Thunderbird main window (or in the message window itself if you opened the message in step 3). Actual Results: Immediately after the new message (forward) window opens, a dialog box appears with the title "Confirm" asking "Would you like to subscribe to ~dusty/Clients^^Some Client Name?" This IMAP server is running on "Linux office 2.2.19 #22 Wed Jun 20 18:12:16 PDT 2001 i686 unknown". IMAPd banner text: "* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=LOGIN] office.ztn IMAP4rev1 2001.315 at Fri, 15 Aug 2003 12:06:18 -0700 (PDT)" I have a cropped screenshot of the dialog box that appears. Also, I have the example email message source. I will post those as attachments to this bug request.
Attachment #129876 - Attachment filename: 200307151218-thunderbirderror-subscribeonforward.gif → 200308151218-thunderbirderror-subscribeonforward.gif
In this attachment, all images have been replaced with blank GIFs. This was removed directly from the folder file stored on the IMAP server.
QA Contact: asa
Possibly related to this is that Thunderbird keeps asking me if I want to subscribe to newsgroups I'm already subscribed to. This has become rather annoying because it also marks all the messages as "unread" (even if I've already read them). I'm not sure what I did to make this happen because it only occurs on one computer. To reproduce, all I have to do is select a newsgroup from the list of subscribed groups.
QA Contact: message-compose
Assignee: mscott → nobody
This bug re occur again after installing the latest update TB 45.7.0 Release Date Jan. 26, 2017 Returning to TB 45.6.0 until this bug will be fixed. Hope somebody will see and fixed this problem. Regards, Jay
Attachment #8831666 - Flags: review+
Attachment #8831666 - Flags: review+
See Also: → 1335007
I confirm this issue. The dialog asking "would you like to subscribe.." opens even when certain - not all - IMAP emails are selected in the message list (at least with the preview window open). We've had to revert to 45.6.0 until this is fixed. Cancel/escape has to be chosen multiple times before the dialog closes.
I confirm the issue. I have a "Would you like to subscribe.." when i open an email. It looks like thunderbird change the img src from "http://path/to.img" by "imap://email@...". This seems to happen when html signature is used. I can see it by using "ctrl+U" on an email where the issue occurs.
I confirm the issue. We have several users at our organization using IMAP who are receiving this issue to a few email threads. We're looking to revert to 45.6 if the problem spreads. the problem seems to be isolated to people who have received a particular email with the exhibited problem, but it does not apply to other emails the same user has sent. "Would you like to subscribe to user/username/INBOX/Folder " Cancel/escape has to be chosen multiple times before the dialog closes. Hopefully this gets patched in the next release.
(In reply to Edward Paine from comment #5) I have been using 45.7.1 for the last 3 days with no sign of this issue, so it looks like it has been fixed.
This bug is back again as of version 52.0.1. Image sources are converted from http://path-to-image to imap://path-to-IMAP folder which breaks as soon as the folder is deleted or renamed and leads to the "Would you like to subscribe.." pop-up at one per embedded image.
It looks like this has been fixed in 52.1.0
Seems not to fix my problem in 52.2.1 (no change to 52.0.1). Can anyone confirm ?
Thunderbird 56.0 How do you stop those infernal popup windows ? I get literally spammed by those "Do you want to subscribe to WATHEVER_URL_THERE"apopup messages as soon as there is a src="imap://WHATEVER@WHATEVER:143/fetch%3EUID%3E/Fidumail%3E476687?part=1.2&amp;filename=FIDSC-1.gif" in the message. It even gets worse if you try to actually respond : each couple of characters typed in the compose window, the popup comes back. Is there a preference to set or a .js to delete so that it doesn't it again for any url i could have in my emails ???? I'm going crazy, this is plain ridiculous.
This issue is back with version 60.2.1 as per my comment #9 (was using 52.9.1 with no problem).
I confirm the issue is back : many of my users have it (and never had it before).
I am also having this issue, using Thunderbird 60.2.1 on Windows 10 (1803) and am seeing it also when moving messages from one folder to another.
We're also having this issue on our corp environment since updating to 60.2.1. Able to replicate the fault but not workaround it. Rolling back to previous version seems to fix the issue, even for emails that have already had their code changed. As mentioned already seems to be an issue with the code being stripped out for signatures here and being replaced with... src="imap://......." As mentioned above. This is becoming a major disruption here as we've recently rolled out 60.2.1 to the business. Has anyone found a workaround at all? Environment Windows 10 Pro Anthony
First post here, hope it helps - took half a day to find a (possible) solution/workaround, so guess it was worth going through the creating account procedure. Had the same issue after upgrading. Some machines worked, silently ignoring the imap://.. links, others produced the prompt. So, after tons of side-by-side trying, discovered the following: The prompt occurs when mail.server.<serverXX>.socketType is set to anything other than '3', for SSL. It can be changed from the config editor, or, much easier: Account Settings > Server Settings > Connection Security: SSL/TLS No more prompts, at least on tb win version 60.3.0 64bit, and assuming your server supports SSL connectivity.
Thanks for the feedback! I have some emails with the imap:// code in place that have been forwarded from other users' in the business and I'm getting those errors pop up. I have SSL/TLS by default, as does everyone in the company. Does not having the SSL selected stop the actual generation of the imap:// code from the sender or is this just a recipient issue on your side? Cheers Anthony
It is sender mailer (or webclient+server) generated, causing recipient issue - checked the stored emails on the server, the imap://.. was there. I also thought SSL was enabled on all machines, seems it wasn't the case after all. Soon as SSL/TLS got enabled, all popups stop (no need for restart). As for the creation of the IMAP://.. links (instead of images), it could be either sender's mailer, or web interface + mail server, i'd presume. Checking the 'sent items' folder of a sender would be the best place to start, assuming a copy has been kept.
Yeah, the error in the code is generated on the client. We've had the issue for weeks now. Opening the items in "sent" generates the error on the sender's machine as well as the recipient's. Suppressing it on the recipient's side would be half the battle won! Testing with the SSL has been inconclusive this side. Disabling SSL on my client seems to work...not on someone else's. Will continue but thanks for the lead! Let me know how you get on... Anthony
Also verified it's client generated. Furthermore, it seems it's client settings -not version- specific. Two machines, same dpt, same tb version. One sends images in signature as attachments, the other generates links. So, the only difference with tb versions, seems to be how those links are handled by the recipient (popups), and not if they are generated or not. Now, as for which setting generates the links, guess will be able to check later today. Will post back any findings.
I confirm this issue still exists with version 60.3.0 (Win), which annoyingly is the first version to prompt users for an automatic upgrade. We use Connection Security: None because our server/clients are all internal, so I can't test whether buying a certificate would fix it. Staying on 52.9.1 until there's more positive news.
No need to buy a certificate. A self-signed one can be used. You can check your server, might have built-in option to generate one. Then, all you have to do when enabling SSL at the clients is to accept the certificate when prompted - for certs from trusted authorities, you get no prompt. There might (should) be a setting in thunderbird for accepting self-signed cets with no verification prompt. I have seen mobile mail clients that offer this option - never had to check if tb does as well, though.
And, the culprit for the creation of the imap://.. links is: mail.inline_attachments Open config editor, set it to true (default), and you are done. Way to check: Open a mail with signature, click reply, scroll to see if the image is visible. If not, inline_attachments is disabled, and the imap:// link will be generated. Change the value to it's default, try the above procedure again, the image in the signature should be visible - and no pop-ups on the recipient side, despite the version. By doing the above, you are sending emails properly. By performing the previous config (SSL, described in previous post), you prevent the recipient's client from generating the popups when a mail with imap:// links is received. Hopefully now that the cause on both ends has been identified, a fix in a future version will be applied.
Thanks for the information, that's really helpful. My personal TB is set to true, but that makes sense as I haven't been generating the code when forwarding emails. Going to run some tests with users today, will let you know how I get on.
And, the issue wasn't fully resolved with the previous method. Seems that the prompt is produced if the type of the IMAP:// link is the same as the connection the recipient is using. E.g, links ending with :993 will produce the popup if the recipient is using SSL. Soooo, if you really want to get rid of the popup -don't know if there are any sideffects-, some easy cracking is required. First, to be on the safe side, make a copy of the file you'll select, and of your profile. Then, with a disk editor (actually, notepad++ worked for me) open either the file omni.ja or xul.dll, in the thunderbird installation folder, search for the string "imapSubscribePrompt", and change one of it's letters. E.g. make it "imapSubscribePrompX". Don't append a letter, just change one - the size must not be modified. This should get rid of the prompts. Now, as for the config that sends the IMAP:// links, I found a machine that did generate them despite having 'inline' enabled (see previous posts). Just removing and adding the account again fixed it. Kept the profile though to check to see what was causing it.
Just confirming this bug still exists with version 60.3.1 (Win). Downgrading again.
Version 60.3.3 still has this bug.
Thanks for letting us know. I'm going to try the above "imapSubscribeprompt". Has their been any adverse side effects to the workaround at all?
No side effects so far - I modify the omni.ja, so i'd say go with that, instead of the xul.dll. Just make sure to change just one character (in place change, preserve filesize), otherwise, thunderbird wont load. As I get it, what the modification does is: thunderbird checks for the function imapSubscribePrompt in omni.js (which would generated the prompt), doesn't find it, and just does nothing instead. If there is interest express here, i'll try to find some time to create a patcher to simplify the procedure.
Question. How do I edit the omni.ja file? My one is blocks of numbers (in the program files dir). Couldn't see one in the profile dir.
It's in program dir. Just search for the string 'ImapSubscribePrompt'. It's located well bellow the initial binary content. line 365906 on the version i just checked.
Hmm, yeah I tried exactly that, the file is there but the content is just number blocks, top to bottom (45mb's worth!) and that string doesn't exist anywhere else...strange. I checked the profile dir too just in case. I'm running 32bit v6.3.0
Haven't tried the 32bit version, just the 64bit one. Which editor did you open the file with? And how many total lines does it report? I suppose that some text editors will truncate a binary file.
Sublime text. Line 365906 "222c 2022 6e6f 726d 616c 222c 2022 7369" Total 2997965 lines.....all the same as above, strange.
Seems like you are viewing the file as hex. Check if there is an option to view as text file. If on windows, try open it with notepad - just to check the content, i wouldn't save it afterwards + it might take a while to load. As mentioned before, I used notepad++. If you can download it. Very good editor, and free.

I can confirm that this bug still exists with version 60.4.0 (32-bit) as per my comment #9
Downgrading to version 52.9.1 fixes it.
It's frustrating that it seems to be taking so long to address. I'll try the self-signed certificate route and report back, but it's still a bug.

As mentioned in previous post, this will not fully address the issue.
A while ago I promised a patcher should I found the time.
If on windows, here it is:
https://rtr.gr/var/ThunderbirdImapSubscribePromptPatcher.zip

Instructions:

  1. Quit Thunderbird, if running.
    2a. Copy the included .exe file to the thunderbird installation folder and run it, or
    2b. Run the included .exe file and select the omni.ja file in your thunderbird installation folder.
  2. Click the 'patch' button.

The above program and the patching method is provided with no warranty of any kind - use at own risk!
All it does is (make a backup copy of omni.ja and) replace the imapSubscribePrompt string in omni.ja with imapSubscribePrompX, as described in previous post.

Please note that until the bug is fixed, after any update the patch will probably have to be reapplied...

60.5.0 (32-bit) still has this issue. Self-signed certificate route was a red herring (for me at least), and the ImapSubscribePrompt edit does need to be re-applied.

Please can you fix it permanently?
#ThunderbirdImapSubscribePromptPatcher is good but after update problem will always come back.
We have hundreds of Thunderbird users and it's still annoying to correct this error.
Thank you.
Tomas

Case it helps:
If your thunderbird installation folder has user r/w access rights, then rename the file to eg: #ThunderbirdImapSubscribePromptFix.exe - something that doesn't include the work patch/patcher.
Including the word 'patcher' in the name, leads to requiring admin rights to run the app - at least on win10.

By default, the program checks for the file to be patched in C:\Apps\MozillaThunderbird.
This is the location I use for new setups - i'm just copying tbird, instead of installing, along with a preconfigured profile.

Anyway, if you use that location, and you have renamed the file, your users will be able to apply the patch themselves with just one click, as they won't even have to browse to locate tbird installation folder.

Just to say this bug is not fixed by 60.6.1

Has anything changed? I tried to use the omni.ja fix, but it did not work anymore (Thunderbird 60.6.1 32Bit).
The Prompt ist still loading despite the wrong name.
A few month ago I did the same on several PC and it was fine.

Just applied the patch to a recently updated to 60.6.1 (64bit on win10) client, and worked as expected - no more subscribe prompts..
Don't have any machines running the 32bit version, so can't test that.

Thunderbird/60.6.1 on Windows have the same problem.
Here the source of mail with imap reference :

 <div class="moz-signature">
      <div class="moz-signature"><a href="http://XXX"
          moz-do-not-send="true"><br>
        </a>
        <title></title>
        <p> <a href="http://XXX" moz-do-not-send="true"><img
src="imap://XXX%2EXXX@imap.XXX:993/fetch%3EUID%3E/Drafts%3E48266?part=&amp;filename=XXX.eml&amp;fetchCompleteMessage=true&amp;filename=logo_site.png"><img
              src="cid:part5.6828833E.6AC6AFC2@XXX" class=""><br>

This bug still exists in 60.7.0. I wonder how we bring this to anyone's attention - maybe it needs a new bug report? In our case at least this is nothing to do with forwarding, it is entirely due to moved/renamed image sources in IMAP folders as per my Comment #9 above.

We also have this problem but only if the mail has been forwarded with a Thunderbird 60.3.3. If I open such a malformed forwarded mail with Thudnerbird 60.7.0, the message is shown (source of mail has been already been malformed a few weeks ago by an older Thunderbird version).
If I (with a Thunderbird 60.7.0) forward a new e-mail with the same signature and embedded picture, eveything works fine.
Is this repoducable by anyone? This would mean the bug in forwarding a message is solved, but consists for already existing forwarded e-mails, which would be normal...

This issue is coming back and forth for so long.
I propose that at least you make it less irritating/ui-blocking by making the dialog passive.

e.g. If subscription options exist, a listbox control appears on the email bar with all these options.
My ubuntu feels like old windows when having to click "cancel" on so many alert-boxes :)

Bug always here.

Forward was from Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 and read on Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1.

<img
src="imap://xxxxx%2Exxxxx@imap.xxxxxx:993/fetch%3EUID%3E/INBOX%3E87440?part=1.2.2&amp;filename=XXXXX-logo.jpg"
data-mce-src="../home/xxx@XXXXX.org/Briefcase/XXXXXX-logo.jpg"
              doc="Briefcase/XXXXXX-logo.jpg" width="176"
              height="132"
See Also: → 1577683
See Also: → 1575330

This bug may be fixed by Bug 1572864. It eliminates the insertion of erroneous "imap://..." links into forwarded or edited as new emails. However, I'm not 100% certain that this bug is fixed since I have not been able to duplicate the problem described in this bug (unexpected requests to subscribe).

The fix is targeted at 60.9 and 68.1 which are not yet released, AFAIK. It probably won't affect emails residing in mailboxes that already have the "imap://..." link in the source but it should prevent the insertion of those links in futures emails created by TB.

Note that bug 1572864 has restricted visibility due to security implication.

I'm afraid this bug isn't fixed in 60.9, although its behaviour has changed a little. I think it's still incorrect addressing of imap folders (even ones that do exist now) but haven't had time to look closer (even if I understood what was going on). Luckily the workaround (edit omni.ja) still works.

(In reply to Edward Paine from comment #51)

I'm afraid this bug isn't fixed in 60.9, although its behaviour has changed a little. I think it's still incorrect addressing of imap folders (even ones that do exist now) but haven't had time to look closer (even if I understood what was going on). Luckily the workaround (edit omni.ja) still works.

Edward, Do you know a fool-proof way to duplicate this? This fool hasn't been able to. :)
Also, editing a file like omni.ja sound like a not good general solution.
In comment 9 you mention that there is an imap:/.... url involved. Is that still the case?

I am seeing this bug's symptom in 68.0-ssl and 69.0b4-ssl (downloaded 9 Sep 2019). with Lightning enabled.
When I open a particular message in folder foo/bar, I get a pop-up "Do you want to subscribe to //foo/bar?"
If I say "Cancel", I see an empty body (no image).

I was the reporter for bug 1572864. While I am not a TB developer, as I understand it, the fix was to remove the security issue. It did not directly address this issue.

In my current case, the image attached to the message (a top-level multipart part) is referenced both within the content (in both alternative text/plain and text/html parts) and in a text/calendar part. The symptom, for this message, occurs only when Lightning is enabled. In safe mode, the message appears as expected.

With Lightning enabled, the subscribe symptom occurs when the message is in a folder different from Inbox. I get these errors when opening the message (first message opened after starting TB 68)

Lightning: Component returned failure code: 0x804a0100 [calIICSService.parseICS] when parsing <apparent binary removed in this bug report> calIcsParser.js:151
[This next line occurs after I cancel the subscribe pop-up]
AttachmentInfo.isEmpty: error - NetworkError when attempting to fetch resource. msgHdrView.js:1932:17

When I moved the message to Inbox, the subscribe pop-up did not appear, but neither did the image. I get these errors in the error log when I open the message (first message opened after starting TB 68)

Lightning: Component returned failure code: 0x804a0100 [calIICSService.parseICS] when parsing
<apparent binary removed in this bug report> calIcsParser.js:151
AttachmentInfo.isEmpty: error - data.value is undefined msgHdrView.js:1932:17

[In TB 69, Lightning was 69. When I went back to TB 68, I had to remove & reinstall Lightning 68]

As for the problematic message, I'm willing to share it with individuals working on the bug, but I'd rather not post it for the world (because it contains email addresses). I'm leary of sanitizing the addresses.

(In reply to Mabry Tyson from comment #53)

Mabry, If you could attach the problem message as an *.eml and send it directly to me that would be great (using my profile address). I never run with Lightning since that is not my area, but I will enable it for this test.

However, if commenter Edward Paine has a way to duplicate the problem without involving Lightning, I still would like to hear about it.

Mabry, I received the .eml but can't duplicate the problem. Details are in the email reply I sent to you.

You mention this error in comment 53:

AttachmentInfo.isEmpty: error - data.value is undefined msgHdrView.js:1932:17

This sounds like maybe it is in the area touched by this bug: Bug 1345167

Gene, I've sent you an email.

(In reply to gene smith from comment #55)

Mabry, I received the .eml but can't duplicate the problem. Details are in the email reply I sent to you.

It appears you gave it a good try. Thanks! Maybe over the weekend I'll have time to figure out why I see it but you don't, and then find a way to make it so others can replicate it.

Early work on click on link causing a subscribe to shared folder; only of historical interest probably: Bug 112105

See Also: → 112105

Still working on this in Bug 1577683. There is some improvement with 68.1.1 however if the email contain "imap://" links there still seems to be a problem due to pre-60.9 TB sometimes dropping the links into emails.

Ed and Mabry, I don't think I asked but do your imap servers advertise "Other user" or "Public" namespace paths in "Advanced Server" setting?

(In reply to Mabry Tyson from comment #57)

(In reply to gene smith from comment #55)

Mabry, I received the .eml but can't duplicate the problem. Details are in the email reply I sent to you.

It appears you gave it a good try. Thanks! Maybe over the weekend I'll have time to figure out why I see it but you don't, and then find a way to make it so others can replicate it.

Mabry, I think some of the problems you saw is probably caused by the patch in Bug 1345167 which turned out to cause regressions in 68.0, 68.1 and maybe 60.9. They are now fixed in version 68.1.1.

But still unable to see a subscribe pop-up with the test message (or other messages) that Edward Paine sent me via email. I think Jorg is also looking at this and maybe he will have better luck with email sent to him by another tb user.

It is mentioned above that going from NONE to SSL/TLS security may fix the problem. I think this is because the imap:// url (that ends in :143, none, or :993, tls) becomes invalid when security is changed so the URL is ignored and no subscribe is attempted. Also, reading comments above, changing this didn't always work.

I set up my local Dovecot imap test server to have shared "Other Users" namespace and have duplicated the problem. Have found a possible solution for when errant "imap://...fetch..." links exist in legacy messages (put there due to a hopefully now fixed bug in tb). I should have a "try" build available shortly so it can be tested by end users; I will post the links to try builds and the proposed patch in the subsequent comments.

Here's a proposed patch that fixes the problem (imap:// links causing spurious subscription request to occur). From my understand, the imap:// links are intented to be put into a message body so the recipient can click on the link and subscribe to a shared folder in the "Other User" namespace. The imap:// link can also cause the recipient to go to another folder in their private namespace when clicked. The imap:// link, when evaluated at the location of this patch, is not intended to cause a fetch or other imap activity so the patch causes the subscribe prompt to not occur when the url contain an imap action such as fetch. (Bug 112105 describes the concept of clicking to subscribe.)

Imap urls with fetch imap action were put into emails due to the other bug that was recently fixed and often cause the spurious subscription prompts (bug 1572864). So this will mostly address legacy emails produced by older TB versions still having the imap:// fetch links.

I will provide links to "try" builds so the various reporters can test the fix in their own environments.

Assignee: nobody → gds
Attachment #9099762 - Flags: feedback?(mkmelin+mozilla)
Attachment #9099762 - Flags: feedback?(jorgk)

Here are the direct links to the "try" build. This is really a 68.1.2 version with the above patch (diff) applied.

Linux x64 opt (manual intall only):
https://queue.taskcluster.net/v1/task/ewQkrgvLTXWp8DeCzsCR7Q/runs/0/artifacts/public/build/target.tar.bz2

Window 2012 x64 opt:
https://queue.taskcluster.net/v1/task/XCK-fZYJR_uPGrizzi4Wjw/runs/0/artifacts/public/build/install/sea/target.installer.exe
or for manual install,
https://queue.taskcluster.net/v1/task/XCK-fZYJR_uPGrizzi4Wjw/runs/0/artifacts/public/build/target.zip

OS X Cross Compiled shippable opt:
https://queue.taskcluster.net/v1/task/TexBw1iOSIaKZULy7vzxvA/runs/0/artifacts/public/build/target.dmg

The links above, and others if something more appropriate is wanted, can also be found here:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7fd6468698c3949164dc14d6ca69fe5697123c7d&selectedJob=270398763
Click on the green "B" next to the architecture type. When clicked, new information appears in the bottom half. Click on
"Job Details" and you can download any of the items listed, including those already listed above. (Most are probably not useful to the end users.)

I tried the Windows x64 Daily in my environment and can confirm no subscribe requests occurred. Great work Gene.

Comment on attachment 9099762 [details] [diff] [review] subscribe-fix.diff (proposed patch) Wow, very old bug from 2003. I think your approach is good and we already have confirmation that it's working. I'm happy to r+ this unless you want feedback from Magnus (who's on PTO this week). I can land the patch if you want and remove the print for you. Let me know.
Attachment #9099762 - Flags: feedback?(jorgk) → review+

I also just asked the reporters for Bug 1577683 to test the "try" build. May want to wait a while for them to check the results before landing.

So ready to go here?

Flags: needinfo?(gds)

(In reply to Jorg K (GMT+2) from comment #67)

So ready to go here?

Only have one confirmation of the fix in the "try" version at Bug 1577683. But I think the fix is OK so go ahead and do your thing.

Flags: needinfo?(gds)

Removed debug and fixed commit message.

Attachment #9099762 - Attachment is obsolete: true
Attachment #9099762 - Flags: feedback?(mkmelin+mozilla)
Attachment #9100762 - Flags: review+
Attachment #9100762 - Flags: approval-comm-esr68+
Attachment #9100762 - Flags: approval-comm-beta+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/0c3697a0269a
Avoid unwanted prompt to subscribe to IMAP folder when imap: URL is found in image src. r=jorgk

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 71.0

Comfortable adding this to the 70 beta?
We have an enterprise user who can test it.

Flags: needinfo?(jorgk)

(In reply to Wayne Mery (:wsmwk) from comment #71)

Comfortable adding this to the 70 beta?
We have an enterprise user who can test it.

Not Jorg but,
Edward Paine above has tested at his business (comment 64). I have also requested several others to test the "try" build in the almost duplicate Bug 1577683. I think some may be enterprises, not sure. (And I tested it on my non-enterprise system.)

Comfortable adding this to the 70 beta?

Yes, I was going to write "not yet" to "tb drivers" to include this bug and potentially others that might become available today or tomorrow.

Flags: needinfo?(jorgk)

Can confirm this as Verified.
Tested on OS WIN(64):
• Version 70.0a1
Build: 20190815101348

•	       Version 71.0a1
             Build: 20190904095558

OS MAC Sonoma 14
Version : 126.0b1
Build: 20240422190155

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

Attachment

General

Creator:
Created:
Updated:
Size: