1729228 - [meta] C-C URL classes should just hold URLs (nsIMsgMailNewsUrl et al)

Status: NEW

(MailNews Core :: Networking, task)

Description

[Ben Campbell]

All the C-C nsIURL-derived classes have extra members which track the state related to individual requests. This is an issue for a bunch of reasons:

1. they are not really just URLs as most people would understand them. They are more like request objects. And this is totally counter to how they are used in the M-C side of things, which assumes URLs are just URLs.

2. it splits up request state needlessly, making everything way more complicated. For example, IMAP requests have their state smeared across nsImapProtocol, nsImapMockChannel and nsImapUrl, among others.

3. it causes all kinds of threading issues. Because our URLs hold pointers to XPCOM objects, using them anywhere except the main thread is a recipe for trouble (e.g. Bug 1175168). But there's no reason for this, and I'd be surprised if M-C didn't assume that URLs can be used on any thread.

covers:
nsImapUrl, nsPop3URL, nsSmtpUrl, nsMailboxUrl, JaBaseCppUrl, nsNntpUrl etc...
most use nsMsgMailNewsUrl as base class, so that's probably a good place to start.

Comment 1

[Ben Campbell]

This state of affairs also means we can't take advantage of sandboxing and process isolation.

Stealing a paragraph Sean wrote about the EWS implementation:

Additionally, we discovered when implementing message display that necko expects that any implementation of `nsIURI` (the generic URI interface used throughout Firefox and Thunderbird) can be fully represented as a URI string so that it may be communicated cross-process. Because `nsIMsgMailNewsUrl` implementations include potentially many fields which are not and cannot be represented as part of a URI string, instances thereof cannot be passed between processes, and m-c has ad hoc provisions for isolating handling of Thunderbird-specific URI schemes to the parent process. This creates an additional burden when implementing a new protocol and makes it impossible to take advantage of the electrolysis/fission work done in Firefox to improve UI performance and application security through sandboxing.