737614 - Remove use of synchronous cache API from nsWyciwygChannel

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[u408661]

Just like in bug 722033 for nsHttpChannel, there is one location in nsWyciwygChannel.cpp where we make use of the synchronous openCacheEntry API. We need make it 100% async.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note that unlike bug 722033 the call here happens on the cache IO thread, not on the main thread.  Does that make a difference?

Comment 2

[u408661]

(In reply to Boris Zbarsky (:bz) from comment #1)
> Note that unlike bug 722033 the call here happens on the cache IO thread,
> not on the main thread.  Does that make a difference?

In practice, yes (since we don't actually block the main thread). However, given that my end goal is to remove the synchronous API entirely, we still need to remove this usage of that API.

It may be possible that we're better off leaving the synchronous API available for internal/native code use, while removing it for script/extensions. However, given that native code use is what causes us most of our headaches (in terms of snappiness), I'm not convinced of that.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, makes sense.  This code should be not too difficult to convert, since it's already doing all this stuff async on the cache thread.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The fix for bug 660749 that I am working on requires all the channels to use asyncOpenCacheEntry, including this one.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Well, perhaps I am mistaken. I need to figure out how session restore loads wyciwyg sessions better before I can tell if this change needs to be made for bug 660749.

Comment 6

[u408661]

Since the only "synchronous" cache call in wyciwyg channels is already done on the cache thread, we're going to keep this call as-is and just remove that API from XPCOM (see bug 739473)