"about:blank" in top-right corner of printed calendars

RESOLVED FIXED in 1.0b4

Status

Calendar
Printing
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Fco. Jose Mulero, Assigned: Fco. Jose Mulero)

Tracking

Lightning 1.0b2
1.0b4
x86
Linux

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.2.11) Gecko/20101013 Ubuntu/9.04 (jaunty) Firefox/3.6.11
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

When printing a calendar always appears the folowing text in the upper right corner: "about: blank"

Reproducible: Always

Steps to Reproduce:
1.Go to calendar view
2.Select File > Print
3.Print calendar to File

Actual Results:  
In the resulting file we can see "about: blank" in the upper right corner.

Expected Results:  
Nothing in tha corner.
(Assignee)

Updated

7 years ago
Version: unspecified → Lightning 1.0b2
(Assignee)

Comment 1

7 years ago
Created attachment 518691 [details] [diff] [review]
Proposed patch

I attach a proposed pathc. I'll accept any type of suggestions

Comment 2

7 years ago
It is only there if you want it. Go to File > Page Setup > Margins & Headers and set a different or none value for the header and footer line.
Comment on attachment 518691 [details] [diff] [review]
Proposed patch

But showing about:blank doesn't make sense in any case, although one might want the mail uri when printing in Thunderbird. I think we should take this fix.


>+ *   Francisco José Mulero <fjmulero@gmv.com>
Please make sure the files you edit are saved as utf8, so the correct letter shows here.

> function printAndClose() {
>     refreshHtml(
>         function finish() {
>-            PrintUtils.print();
>+            var webBrowserPrint = PrintUtils.getWebBrowserPrint();
>+            var printSettings = PrintUtils.getPrintSettings();
>+            // Evicts "about:blank" header
>+            printSettings.docURL = " ";
>+            try {
>+                webBrowserPrint.print(printSettings, null);
>+                if (gPrintSettingsAreGlobal && gSavePrintSettings) {
Do we really have to save these print settings? I would prefer if we could just make sure that no URL is shown when printing calendars.

>+            } catch (e) {
>+                // Pressing cancel is expressed as an NS_ERROR_ABORT return value,
You could use } catch (e if e instanceof Components.results.NS_ERROR_ABORT) {


r+ with those nits fixed, I'd appreciate if you could upload a new patch for checkin and request review from me so it doesn't leave my radar.




>             let closeDialog = true;
> #ifdef XP_UNIX
> #ifndef XP_MACOSX
>             closeDialog = false;
> #endif
> #endif
Since you've looked into printing support a bit, maybe you could help us a bit further here. Take a look at bug 351581. The problem is there, that when the dialog is closed then printing is no longer possible. I assume that since the window is closed, the html tree also goes away. Maybe you can find a way to create the html tree in the parent window (or the hidden window, if on mac) so we can fix this issue too?
Attachment #518691 - Flags: review+
(Assignee)

Comment 4

7 years ago
Created attachment 519875 [details] [diff] [review]
Corrections
(Assignee)

Comment 5

7 years ago
(In reply to comment #3)
> Comment on attachment 518691 [details] [diff] [review]
> Proposed patch
> 
> But showing about:blank doesn't make sense in any case, although one might want
> the mail uri when printing in Thunderbird. I think we should take this fix.
> 
> 
> >+ *   Francisco José Mulero <fjmulero@gmv.com>
> Please make sure the files you edit are saved as utf8, so the correct letter
> shows here.
> 
> > function printAndClose() {
> >     refreshHtml(
> >         function finish() {
> >-            PrintUtils.print();
> >+            var webBrowserPrint = PrintUtils.getWebBrowserPrint();
> >+            var printSettings = PrintUtils.getPrintSettings();
> >+            // Evicts "about:blank" header
> >+            printSettings.docURL = " ";
> >+            try {
> >+                webBrowserPrint.print(printSettings, null);
> >+                if (gPrintSettingsAreGlobal && gSavePrintSettings) {
> Do we really have to save these print settings? I would prefer if we could just
> make sure that no URL is shown when printing calendars.
Unfortunately I don't have much experience, I spent quite some time, and this was the only satisfactory solution. I will try to improve it, but I can't ensure that I success.
> 
> >+            } catch (e) {
> >+                // Pressing cancel is expressed as an NS_ERROR_ABORT return value,
> You could use } catch (e if e instanceof Components.results.NS_ERROR_ABORT) {
> 
> 
> r+ with those nits fixed, I'd appreciate if you could upload a new patch for
> checkin and request review from me so it doesn't leave my radar.
> 
> 
> 
> 
> >             let closeDialog = true;
> > #ifdef XP_UNIX
> > #ifndef XP_MACOSX
> >             closeDialog = false;
> > #endif
> > #endif
> Since you've looked into printing support a bit, maybe you could help us a bit
> further here. Take a look at bug 351581. The problem is there, that when the
> dialog is closed then printing is no longer possible. I assume that since the
> window is closed, the html tree also goes away. Maybe you can find a way to
> create the html tree in the parent window (or the hidden window, if on mac) so
> we can fix this issue too?

I can't  see the problem, the current solution works and is homogeneous in all platforms.
Comment on attachment 519875 [details] [diff] [review]
Corrections

Ok, lets take this patch. I see that printUtils does it just the way you do. r=philipp
Attachment #519875 - Flags: review+
Attachment #518691 - Attachment is obsolete: true
Assignee: nobody → fjmulero
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/2f749ef7d9ba>
-> FIXED
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
You need to log in before you can comment on or make changes to this bug.