976183 - Folder panes not being constructed (due to issue with 10.9 SDK).

Status: RESOLVED WORKSFORME

(Thunderbird :: Build Config, defect)

Description

[Josiah Bruner [:jsbruner]]

Starting today, both the main folder pane (on the three-paned window) and the pane in the chat tab, occasionally fail to construct and show up, but not every time.

This definitely needs to be fixed. I'm going to continue investigating...

This may be OS X only.

Comment 1

[aleth [:aleth]]

The relevant error seems to be 
Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.compareSortKeys]
Source File: chrome://messenger/content/folderPane.js
Line: 2324

This is clearly a regression.

Comment 2

[Josiah Bruner [:jsbruner]]

This doesn't seem to happen in the 2-23-2014 build. So that helps.

Comment 3

[Josiah Bruner [:jsbruner]]

That means we're looking for landings on the 23rd - 24th.

C-C: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=badfd6923c90&tochange=6e585f3aa138

M-C: https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=yesterday&enddate=today

Comment 4

[Josiah Bruner [:jsbruner]]

Ah, shoot. Just reproduced on the 23rd build, so it does go back farther.

Comment 5

[Josiah Bruner [:jsbruner]]

I've tested a lot more and it seems to work on the 22nd.

There were no C-C changes from the 22nd to the 23rd (that would matter), so that at least limits things down to M-C.

https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-02-21&enddate=2014-02-22

Comment 6

[Josiah Bruner [:jsbruner]]

Oops. I meant:

https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-02-21&enddate=2014-02-23

Comment 8

[iamjayakumars]

Attachment: Screen Shot 2014-03-03 at 21.03.34.png

Same issue in Thunderbird 27 and Daily(30.0.1)

Comment 9

[Josiah Bruner [:jsbruner]]

So this isn't good at all. If it's happening on 27 that means either:

* This is caused by a system bug.

* Something was landed and then uplifted to 27 that caused this

* Something else.

Either way, we need as many people as possible working on this, as it breaks TB on OS X.

If you know anyone who might have some knowledge, please CC them.

Comment 10

[iamjayakumars]

THUNDERBIRD 27
 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0

Error Console

http://pastebin.mozilla.org/4455937

Comment 11

[Josiah Bruner [:jsbruner]]

So although iamjayakumars' issue looks sort of related, I'm not sure it's the same problem, since this really shouldn't be happening on 27, and I can't reproduce that myself.

Comment 12

[Josiah Bruner [:jsbruner]]

(In reply to aleth from comment #1)
> The relevant error seems to be 
> Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIMsgFolder.compareSortKeys]
> Source File: chrome://messenger/content/folderPane.js
> Line: 2324
> 
> This is clearly a regression.

For some reason I don't get this message? Did this come from the error console?

Comment 13

[Josiah Bruner [:jsbruner]]

Nevermind, that came from the debugger, I can reproduce that.

Comment 14

[Josiah Bruner [:jsbruner]]

So it turns out this was caused by the 10.9 SDK, so only local builds are affected.

To fix this add ac_add_options --with-macos-sdk=path/to/10.8.sdk to your .mozconfig.

The specific issue here is the UCCompareCollationKeys in CoreServices.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

We should update the build docs.

Comment 16

[Josiah Bruner [:jsbruner]]

Done. https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build#OS_X_10.9_Notice

Comment 17

[Nomis101]

I also had this issue while trying to build TB 31. It took me two days of testing and building with different settings to find out what the problem was. To than finally find this bug here.
Will this be fixed, so its possible to build with the 10.9 SDK? I would really like to build with the 10.9 SDK.
And, why is the status set to resolved? It's not fixed at all, to use the 10.8 SDK is not a fix, its a workaround!

Comment 18

[Josiah Bruner [:jsbruner]]

Because we technically don't support building with anything higher than the 10.6 SDK. So this is a non-issue until we drop support for Snow Leopard, Lion, and Mountain Lion (which is over a decade away).

Also, this is most likely an issue on Apple's side, so there's not much we can do except workaround our own code for Apple's mistake. This is unnecessary if we can use an older SDK.

Of course, someone (me?) should file a rdar about this to Apple, but we'd need a lot more information about the root cause, which I don't have time to inspect now.

Comment 19

[Josiah Bruner [:jsbruner]]

I'm CCing Stephen and Markus (Who work on Cocoa stuff as well) to see if they have any other concerns/ideas though...

Comment 20

[Josiah Bruner [:jsbruner]]

(In reply to Nomis101 from comment #17)
> Will this be fixed, so its possible to build with the 10.9 SDK? I would
> really like to build with the 10.9 SDK.

Just as a question, is there a specific reason you need to be able to use the 10.9 SDK? We don't accept patches that only support specific platforms.

Comment 21

[Josiah Bruner [:jsbruner]]

(In reply to Josiah Bruner [:JosiahOne] from comment #19)
> I'm CCing Stephen...

Err... Excuse me, *Steven* is what I meant.

Comment 22

[Nomis101]

(In reply to Josiah Bruner [:JosiahOne] from comment #18)
> Also, this is most likely an issue on Apple's side, so there's not much we
> can do except workaround our own code for Apple's mistake.
OK, I see.

> Of course, someone (me?) should file a rdar about this to Apple, but we'd
> need a lot more information about the root cause, which I don't have time to
> inspect now.
What would be the proceeding to inspect this? Maybe I could help, at least a bit.

(In reply to Josiah Bruner [:JosiahOne] from comment #20)
> (In reply to Nomis101 from comment #17)
> > Will this be fixed, so its possible to build with the 10.9 SDK? I would
> > really like to build with the 10.9 SDK.
> 
> Just as a question, is there a specific reason you need to be able to use
> the 10.9 SDK?
You a right, at the moment there is no real benefit of building with the 10.9 SDK. But, first, you never know when code will be implemented that will need the 10.9 SDK (Bug 883824). And, second, more important, building TB by our own is currently very tricky. First, I was hitting Bug 950332 (which is not documented in the build docs, by the way). Than, after I had a workaround for that, I was hitting this folder pane bug. So I also had to workaround this. Therefore I think, fixing at least one of those bugs would make it less troublesome for every like me, who are builing their own version of TB.

Comment 23

[Josiah Bruner [:jsbruner]]

Note that is bug *is* mentioned in the Simple TB build docs though.

Comment 24

[Markus Stange [:mstange]]

(In reply to Josiah Bruner [:JosiahOne] from comment #14)
> The specific issue here is the UCCompareCollationKeys in CoreServices.

Do you have more information on what exactly is wrong with UCCompareCollationKeys? How did you find out that that's what's responsible?

Comment 25

[Josiah Bruner [:jsbruner]]

I can't tell you without looking at a few things to refresh my memory. But I'll get a detailed synopsis either tomorrow or Monday for you that will answer those questions.

Comment 26

[iamjayakumars]

The problem happened in MAC OS X 10.9.3, after some important update of OS X. now its working awesome. No issues in thunderbird folder panes

Comment 27

[Josiah Bruner [:jsbruner]]

So the error message in the console was:

"Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.compareSortKeys]"

Here's the relevant compareSortKeys method:

http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#5385

Which has this call:

gCollationKeyGenerator->CompareRawSortKey(argsHere);

That eventually brings us to here:

http://mxr.mozilla.org/comm-central/source/mozilla/intl/locale/src/mac/nsCollationMacUC.cpp#184

(We know we are in the right place now because the issue *only* occurred on OS X, and this is the only relevant OSX-only part of sortKeys)

Then, since the ::UCCompareCollationKeys was the only call to the Cocoa APIs, I knew it had to relate to that line. But the issue didn't exist on people building on OS X 10.8 and down, so I figured that since the concerning line was a CoreSevices call and I could not reproduce on 10.8 SDK or lower, the issue HAS to be that method.

Here's the Apple docs for that: https://developer.apple.com/library/mac/documentation/Carbon/reference/Unicode_Utilities_Ref/Reference/reference.html

I suppose there's a chance that method is not the issue, but I doubt that. Let me know if you need more information.

Comment 28

[Nomis101]

Which version of Xcode have you used for your build, 5.1.1?

Comment 29

[Steven Michaud [:smichaud] (Retired)]

It'd be nice to get to the bottom of this, but it's not urgent -- as far as I know, it's not yet urgent that we fully support building with the 10.9 SDK.

As Markus has noticed, we particularly need to figure out what's different about UCCompareCollationKeys() in the 10.9 SDK.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

https://developer.apple.com/library/mac/documentation/Carbon/reference/Unicode_Utilities_Ref/Reference/reference.html

It's not deprecated, unlike some of the other Unicode Utilities calls.

Comment 31

[Nomis101]

Interestingly, I don't see this issue if I build TB with the 10.10 SDK.

Comment 32

[Andreas Wagner [:TheOne] [use NI]]

:JosiahOne assumes this is an Apple Bug in 10.9. Keeping comment 31 in mind, should we just retest when 10.10 is available and then close this bug if it works fine with 10.10 final?

Comment 33

[Philipp Kewisch [:Fallen][📱📆]]

10.10 is available now, anyone bold enough to update?

Comment 34

[Nomis101]

I have tested this with all Developer previews and with the final version and with all versions of Xcode for 10.10 (6 and 6.1). Building with the 10.10 SDK never showed me this problem.
I have also tested if one of this builds is working nicely on 10.7, and it did. So I think, this issue is solved in the 10.10 SDK.