I can confirm this bug. I get the exact same error on my machine. The regular Thunderbird build from Mozilla has no such issue. An Icedove specific patch seems to be breaking something.

it actually looks like icedove was abandoned in 2017, in favor of thunderbird. icedove was debians project based on thunderbird, but it looks like they did not continue development. i was unaware at the time of installation

[[https://wiki.debian.org/Icedove/Devel]] (last updated 2017)

[[https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian#Icedove]] (notes on debranding back to thunderbird in debian stable in 2017)

so this issue can probably be closed up, unless there is active development of icedove, which i cannot confirm

our Icedove is built from the current-ish thunderbird source.
Icedove on Parabola is far from abandoned.

I'll double check that this issue still exists since Icedove would have been rebuild against the latest ICU

If the issue remains I'll mark it as confirmed

people often have that confusion, being under the impression that iceweasel, icedove were debian projects, as something notably distinct from mozilla

just for the record, the debian iceweasel and icedove were never more than re-branded mozilla releases (mainly just a different name and logo) - that was done only to avoid presumed tradmemark conflicts - they really did not qualify as distinct software projects - all that debian "abandoned" was those names and logos after the tradmemark issue was resolved - the software was always exactly the same as mozilla

parabola and (and other distros such as connochaetos) were coincidentally using the same names and logos as debian; but the parabola iceweasel and icedove have always been significantly different from the vanilla mozilla releases, and therefore, significantly different from the former debian packages

May be tangentally related to this error/warning thrown at startup:

[Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIPrefBranch.getComplexValue]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: resource:///modules/mailnewsMigrator.js :: MigrateDefaultCharsets :: line 180"  data: no]
-- Exception object --
+ toString (function) 3 lines
+ name (string) 'NS_ERROR_MALFORMED_URI'
+ message (string) 'Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIPrefBranch.getComplexValue]'
+ result (number) 2152398858
+ filename (string) 'resource:///modules/mailnewsMigrator.js'
+ lineNumber (number) 180
+ columnNumber (number) 0
+ data (object) null
+ stack (string) 254 chars
+ location (object) JS frame :: resource:///modules/mailnewsMigrator.js :: MigrateDefaultCharsets :: line 180
*
-- Stack Trace --
MigrateDefaultCharsets@resource:///modules/mailnewsMigrator.js:180:24
migrateMailnews@resource:///modules/mailnewsMigrator.js:34:5
OnLoadMessenger@chrome://messenger/content/msgMail3PaneWindow.js:406:3
onload@chrome://messenger/content/messenger.xul:1:1

still broken

Hi, I have the same issue in a Parabola systemd/LXDE Beta installation:

JavaScript error: chrome://messenger/content/AccountManager.js, line 689: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgMailSession.topmostMsgWindow]

theres not much point in fixing v60 now that v68 is out - maybe this bug will vanish on its own by moving forward

i synchronized the PKGBUILD with arch today and started a build but the patches need re-working - i will push the pending changes to abslibre anyways

initially it is the search-engines patch; which is always a pain and has changed significantly in >= v68 - the obvious question to ask is: "why does a mail client need a search engine?" - o/c the obvious answer is "it doesnt - it is not a web browser" - i would expect this friction with seamonkey if and when that moves up to v68; but for icedove, i would suggest disabling that feature if possible - presumably, it would fall-back to launching the system web browser for clicking URLs; so i doubt any important functionality would be lost

For some reason I started to get this problem too, after (accidentally) I almost remove my whole /home

Hope that Icedove v68 fixes this

Nice. I would love to try it right now, but unfortunately I cannot upgrade because icedove now depends on icu >=65.1-2 while iceweasel still depends on icu<65. I will give it a shot once a new iceweasel build comes out.

the latest build 68.2.2-2.parabola1 has the same problem; but the error moved to line 789 - probably the important thing to note here is that this bug was not present when i built this last month, but that was maybe because i did not apply any patches or branding (essentially i had the mozilla thunderbird)

JavaScript error: chrome://messenger/content/AccountManager.js, line 789: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgMailSession.topmostMsgWindow]

I tried the new version but I still get the error

BTW we (I) messed up with the epoch - pacman will see the icedove 68.2.2-2.parabola1 as a downgrade, and -Syu wont install it - if anyone wants to try this today a manual step is needed before upgrading fully

# pacman -Sy icedove && pacman -Su

I've just updated to 68.2.2 and I can confirm that the error is still there.
I also tried 68.2.2 from Mozilla and the email account creation window opens on it.
As bill-auger pointed out, this seems to come from one of the Parabola patches.

Same bug with Icedove 68.2.2 in x86_64 version.

tl;dr: In line 491 of thunderbird-68.2.2/comm/mailnews/base/prefs/content/accountUtils.js, replace else if (...) by else to make it work.

Full version:
Hi everyone, I found (and kinda solved) the problem causing this bug. In the Thunderbird sources, file thunderbird-68.2.2/comm/mailnews/base/prefs/content/accountUtils.js in line 491 (part of the function msgNewMailAccount()), the name "thunderbird" is hardcoded:

  if (existingWindow) {
    existingWindow.focus();
  } else if (AppConstants.MOZ_APP_NAME == "thunderbird") {
    // disabling modal for the time being, see 688273 REMOVEME
    window.openDialog(
      "chrome://messenger/content/accountcreation/emailWizard.xul",
      "AccountSetup",
      "chrome,titlebar,centerscreen",
      { msgWindow, okCallback, extraData }
    );
  }

There is an easy workaround: One just needs to replace the "thunderbird" by "icedove" in line 491, or replace the else if (...) by just an else. When doing so, everything works as expected.

Of course, this workaround is kinda ugly -- why is "thunderbird" hardcoded there in the first place? I did a little bit of research and found out: The conditional was introduced into upstream Thunderbird in Bugzilla bug no. 1338795, see https://bugzilla.mozilla.org/show_bug.cgi?id=1338795. In this issue, some functionality that was used only by Thunderbird was moved from comm/mailnews/ (which has code shared by Thunderbird and SeaMonkey) to comm/mail/ (the directory for Thunderbird code). msgNewMailAccount() opens the "Email Wizard" Window, which is part of this moved functionality.
Even though SeaMonkey does not call msgNewMailAccount(), the developers were afraid that the function could be called from outside Thunderbird (see comment no. 5 in the Bugzilla bug), and thus introduced the bad hardcoded check.
I don't understand why they introduced this check though: there are lots of functions in source files in comm/mailnews/ which rely on functionality in Thunderbird, but this doesn't matter for SeaMonkey, since all references to these functions are disabled when not building Thunderbird. So this check is simply not needed.

Thus, I see this as a bug in Thunderbird and will open an issue on Bugzilla (there are lots of functions in comm/mailnews/ which could/should be moved into /comm/mail/ ... well, maybe they'll do that as well). Hopefully, the change will make its way into upstream Thunderbird in a few versions, and we won't need a workaround any more.

Until this happens, we should add a patch replacing the else if (...) in by else.

Thank you fol solving this! I will prepare a patch and rebuild the package tonight.
If you do create a bug upstream, please link it here, so that we can keep track of that progress

Thank you so much! You rock!!

oaken-source, could you also take care of the branding issue in #2668 when rebuilding? Thanks a lot!

pks40 -

thanks a lot for investigating this - if you open a bug
report upstream about this, please do add a link to this ticket

I just opened a bug in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1628296
Let's hope that helps ...