Editor saving APIs suck rocks

VERIFIED FIXED in mozilla0.9.9



17 years ago
17 years ago


(Reporter: Akkana Peck, Assigned: Akkana Peck)



Firefox Tracking Flags

(Not tracked)




17 years ago
There are lots of different ways to save.  The editor has OutputToString and
OutputToString, but it actually doesn't use either one when it saves; instead it
calls an interface in nsIDiskDocument, which lives somewhere else entirely even
though (I think) it's editor-specific code which is not used by anyone except
editor.  (When the browser saves it does something else again -- fetches from
netlib and saves that without looking at the dom.)  Then there's
nsIDocumentEncoder, which was meant to be a generic interface but I don't think
the nsIDiskDocument stuff is using it.  Mail/News code supposedly depended on
the editor's OutputToStream code (which was the only client for that interface)
but Kathy says no one's using it any more (so what is mail/news using now?)

We need a consistent interface that everyone can call.  We should do this in
time for publishing, before we have to write more bad code dependant on the
inconsistent interfaces.

I suspect that we should use nsIDocumentEncoder and have wrappers inside editor,
unless someone makes a case that someone outside editor needs something that's
in nsIDiskDocument that nsIDocumentEncoder doesn't provide.

Comment 1

17 years ago
Targeting sooner than moz 1.0, so we can have it in place before the bulk of
publishing needs to be written.
Target Milestone: --- → mozilla0.9.6

Comment 2

17 years ago
Note that there are a number of different saving scenarios, so I don't think it 
can be a case of 'one output routine fits all'. Saving scenarios:

1. Saving from the browser. In this case, we need to save exactly what the
   web server served up, so getting it from necko/the cache is the right thing
   to do. However, there does need to be a way to save as text (this might use
   the following).

2. Saving from editor (editor save, mail etc). This needs to do DOM->html or text

nsIDiskDocument's main role is to associate a file on disk (or perhaps on a 
remote server) with an in-memory nsDocument. A part of that role is manageing 
document dirty status. It does not necessarily have to deal with document output.

Comment 3

17 years ago
I should clarify: I'm only suggesting a mechanism for the dom-to-output case,
not for the netlib-to-output (browser can handle that as they see fit).

Editor handles dirty bit management, doesn't it?  Does anyone else besides
editor need that?

With publishing, the association between dom and "disk" becomes more complicated
(since it may be an association between a dom tree and some remote publishing
site somewhere).


17 years ago
Depends on: 104883

Comment 4

17 years ago
We've looked at this a bit but it's not going to be solved in time for 0.9.7. 
Pushing off.
Target Milestone: mozilla0.9.6 → mozilla0.9.7


17 years ago
Depends on: 11035

Comment 5

17 years ago
We're making some progress, but aren't going to be ready for 0.9.7 -- changing
TM to track depandant bugs.
Depends on: 99642
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 6

17 years ago
Work continues ... but won't be finished for this milestone.
Target Milestone: mozilla0.9.8 → mozilla0.9.9


17 years ago
Keywords: nsbeta1+

Comment 7

17 years ago
Really, the biggest issue here was getting the nsIDiskDocument out of the tree,
and switching to use nsIWebBrowserPersist.  The dependencies here weren't well
done (the first one was apparently a wrong number, and the second is Futured for
freezing the API).  But Kathy just removed nsIDiskDocument, and saving no longer
sucks rocks, and therefore I'm closing this bug. :-)
Last Resolved: 17 years ago
No longer depends on: 11035, 99642
Resolution: --- → FIXED

Comment 8

17 years ago
Akkana please verify and mark verified-fixed...thanks!

Comment 9

17 years ago
Akkana please verify and mark verified-fixed...thanks!


17 years ago

Comment 10

17 years ago
You need to log in before you can comment on or make changes to this bug.