Closed
Bug 640925
Opened 13 years ago
Closed 13 years ago
"about:blank" in top-right corner of printed calendars
Categories
(Calendar :: Printing, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b4
People
(Reporter: fjmulero, Assigned: fjmulero)
Details
Attachments
(1 file, 1 obsolete file)
2.93 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
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•13 years ago
|
Version: unspecified → Lightning 1.0b2
Assignee | ||
Comment 1•13 years ago
|
||
I attach a proposed pathc. I'll accept any type of suggestions
Comment 2•13 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 3•13 years ago
|
||
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•13 years ago
|
||
Assignee | ||
Comment 5•13 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 6•13 years ago
|
||
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+
Updated•13 years ago
|
Attachment #518691 -
Attachment is obsolete: true
Updated•13 years ago
|
Assignee: nobody → fjmulero
Comment 7•13 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/2f749ef7d9ba> -> FIXED
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•