1800606 - Stop using nsSyncStreamListener

Status: RESOLVED FIXED

(Thunderbird :: Upstream Synchronization, defect)

Description

[Geoff Lankow (:darktrojan)]

Bug 1800344 has killed off the nsSyncStreamListener::Create constructor which we use to create nsSyncStreamListeners in JS. We only do this in two places in the calendar, and I'm sure this isn't the first time I've had a fight with them because of the stream listener. Let's just do it a different way.

Comment 1

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1800606 - Stop using nsSyncStreamListener. r=#thunderbird-reviewers

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/364bcd649780
Stop using nsSyncStreamListener. r=mkmelin

Comment 3

[Martin Giger [:freaktechnik]]

Sadly there's also a bunch of usage in tests (test_detachToFile, test_mimemaltdetach, test_imapAttachmentSaves, test_quarantineFilterMove and ComposeHelpers.jsm)

Comment 4

[Martin Giger [:freaktechnik]]

Attachment: Bug 1800606 - Stop using nsSyncStreamListener in tests. r=#thunderbird-reviewers

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Geoff Lankow (:darktrojan) from comment #0)

Bug 1800344 has killed off the nsSyncStreamListener::Create constructor which we use to create nsSyncStreamListeners in JS.

Sorry for the trouble! I'm glad this seems to have been straightforward to address, though.

For context: I was looking at nsSyncStreamListener::Create (and just removed it as a simplification opportunity) after filing bug 1800152, which seems to be a Thunderbird stack-exhaustion crash, with infinite event-loop-spinning recursion inside that function. (nsSyncStreamListener::Create causing an event loop spin during which we call nsSyncStreamListener::Create again, etc.)

I wonder if the cleanups here might impact that infinite recursion bug at all, or if any of the folks here have any ideas about what might be going on in that bug?

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f62a51244eca
Stop using nsSyncStreamListener in tests. r=darktrojan

Comment 7

[Geoff Lankow (:darktrojan)]

(In reply to Daniel Holbert [:dholbert] from comment #5)

For context: I was looking at nsSyncStreamListener::Create (and just removed it as a simplification opportunity) after filing bug 1800152, which seems to be a Thunderbird stack-exhaustion crash, with infinite event-loop-spinning recursion inside that function. (nsSyncStreamListener::Create causing an event loop spin during which we call nsSyncStreamListener::Create again, etc.)

I wonder if the cleanups here might impact that infinite recursion bug at all, or if any of the folks here have any ideas about what might be going on in that bug?

I don't think I have any useful insight here, and I'm not sure why anything would be using Open instead of AsyncOpen (as mentioned in the other bug) unless it's the sync stream listener we've just stopped using. For curiosity's sake, I'll change that function to return NS_ERROR_NOT_IMPLEMENTED and do a Try run to see if anything breaks.

Comment 8

[Geoff Lankow (:darktrojan)]

I don't think I have any useful insight here, and I'm not sure why anything would be using Open instead of AsyncOpen (as mentioned in the other bug) unless it's the sync stream listener we've just stopped using. For curiosity's sake, I'll change that function to return NS_ERROR_NOT_IMPLEMENTED and do a Try run to see if anything breaks.

Doing this found one place in product code that calls open instead of asyncOpen on a mail channel, and at least one in tests. (If I'd looked up channel.open in searchfox that also would've found them, but I'm not that smart.) These can (should) be changed.

Comment 9

[Ben Bucksch (:BenB)]

See bug 1800789.