Bugzilla

I should probably have called out [this comment](https://phabricator.services.mozilla.com/D88703#inline-504902) in the phabricator revision here in the bug comments too. I said:

```
This approach makes things much more robust than our current nsIWebProgressListener setup BTW, where if an error occurs along that codepath (there are tons of potential return points) then the caller in the parent process is never notified of failure (the spinner showing the user we're waiting for the PP doc to load will spin for ever).
```

So if we at some point discover that the printing error rate is higher in the new printing UI, it may [in part] be due to the error catching approach (and thus error reporting) being more robust.

I should probably have called out [this comment](https://phabricator.services.mozilla.com/D88703#inline-504902) in the phabricator revision here in the bug comments too. I said:

```
This approach makes things much more robust than our current nsIWebProgressListener
setup BTW, where if an error occurs along that codepath (there are tons of potential
return points) then the caller in the parent process is never notified of failure (the
spinner showing the user we're waiting for the PP doc to load will spin for ever).
```

So if we at some point discover that the printing error rate is higher in the new printing UI, it may [in part] be due to the error catching approach (and thus error reporting) being more robust.