Created attachment 576358 [details] [diff] [review] patch From bug 701797 comment 9: In order to use the download manager to track printing status, we need to fire STATE_IS_NETWORK notifications, since that's what the download manager expects. I'm not sure if this fix is hacky or not, but it doesn't look like it will cause any trouble.
(Note: I'm planning on closing bug 701797 and obsoleting the version of the patch in there, but thanks to bug 704699 I can't do that yet!)
Comment on attachment 576358 [details] [diff] [review] patch Looking at how docloader does this: 1) The STATE_STOP for STATE_IS_DOCUMENT comes before STATE_IS_NETWORK. I believe the API actually requires this. 2) The STATE_START for STATE_IS_NETWORK comes at the same time as STATE_IS_DOCUMENT. That is, there is a single call with STATE_START|STATE_IS_DOCUMENT|STATE_IS_NETWORK as the flags. We definitely need to do #1, and I think it's a good idea to do #2 as well.
Created attachment 577196 [details] [diff] [review] patch v2 I also saw that the STATE_START wasn't being fired anyway because of a check in DoOnProgressChange. I decided to remove that check, since the only caller of DoOnProgressChange that passes 0 for aProgress is the call in OnStartPrinting, and we don't actually want that one to be ignored. (I also fixed a s/progess/progress/ typo.)
I filed bug 705699 to don't clutter this one and to make it easier for people to find it in queries.
Comment on attachment 577196 [details] [diff] [review] patch v2 r=me
Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/af0a7f54f483
I backed out and relanded this, since the original push had some additional unicode char in the commit message, and that confused buildbot sendchange https://hg.mozilla.org/integration/mozilla-inbound/rev/f3f0901e47ff