178215 - add a dropdown menu to the print toolbarbutton

Status: VERIFIED WONTFIX

(Firefox :: Toolbars and Customization, enhancement)

Description

[Noname]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021103 Phoenix/0.4

Comment 1

[David P James]

Or perhaps a small arrow icon below the print icon, as is the case with back and
forward buttons.

-->Confirming as New for developer review

Comment 2

[Simon Paquet [:sipaq]]

Taking QA Contact

Comment 3

[Vedran Miletic]

I like the suggestion in comment #1 because:
1) Thunderbird and SeaMonkey use it.
2) Takes less space on toolbar.

Comment 4

[Steffen Wilberg]

Fixing typo in summary. Assigning to Pierre since he's working hard on print
preview currently.

Comment 5

[Steffen Wilberg]

Attachment: patch

This adds a context menu to the print toolbarbutton: print, print preview and
page setup. Reuses labels and accesskeys.

Comment 6

[Steffen Wilberg]

Adjusting summary, taking and targetting.

Comment 7

[Steffen Wilberg]

Comment on attachment 136957 [details] [diff] [review]
patch

Pierre, how about a little distraction? :)

Comment 8

[Steffen Wilberg]

Currently the order is this: Print, Print Preview, Page Setup.
Should it be like in the file menu instead (Page Setup, Print Preview, Print)?

Comment 9

[Steffen Wilberg]

We could also format the "Print" menuitem bold by adding default="true".

Comment 10

[Pierre Chanial]

Comment on attachment 136957 [details] [diff] [review]
patch

the context menu is a suboptimal solution: that would be the only button with a
context menu and thus would not be easily discoverable.
Ben and I think it should be a drop down menu.

Comment 11

[Steffen Wilberg]

Attachment: add a dropdown menu

I agree that a dropdown menu (to be leftclicked on the arrow) is more
discoverable. This patch adds that, but still adds a context menu (to be
rightclicked) to be consistent with the back and forward buttons, which have
both as well.

Left-clicking the print button calls the print dialog, like before.
Left-clicking the dropdown arrow calls the menupopup.
Right-clicking either one calls the context menu.

I haven't found out how to use the popup "printMenu" as a menupopup as well.
But I defined cmd_pagesetup and cmd_printpreview so that I don't have to copy
the commands over and over. They're now used 3 times in browser.xul.

Comment 12

[Steffen Wilberg]

Comment on attachment 136977 [details] [diff] [review]
add a dropdown menu

I've also rearranged the menu, the order is now Page Setup, Print Preview,
Print.
This is the same as in the File menu, and the Print command isn't as important
on the dropdown/context menu as the other options.

Comment 13

[Pierre Chanial]

Comment on attachment 136977 [details] [diff] [review]
add a dropdown menu

could you remove the context menu and use the print preview and page setup
commands in the file menu?

Comment 14

[Pierre Chanial]

updating summary

Comment 15

[Steffen Wilberg]

> could you remove the context menu
no problem.

> and use the print preview and page setup commands in the file menu?
I'm not sure what you mean, Pierre. Do you want me to use the new commands
cmd_pagesetup and cmd_printpreview in the File menu as well? I already do,
that's the change to browser-menubar.inc.
Or do you not want me to define these commands and use
PrintUtils.showPageSetup();  and PrintUtils.printPreview(...) in the dropdown menu?

Comment 16

[Steffen Wilberg]

Attachment: dropdown menu only

This adds a dropdown menu only. No context (rightclick) action. Leftclick on
the dropdown arrow to show the menu.
This patch (still) uses cmd_pagesetup and cmd_printpreview. Also in the File
menu.

Comment 17

[Steffen Wilberg]

Comment on attachment 137003 [details] [diff] [review]
dropdown menu only

Pierre, is this what you mean?

Comment 18

[Pierre Chanial]

yes, that's what I meant.
I tried this patch, but there are tooltips "Print this page" on the menuitems.
That's clearly wrong and visible, but I am not sure what to do about that. Maybe
we would wait to fix the problem before letting it go.
(btw, the print menuitem should be first with default="true")

Comment 19

[Steffen Wilberg]

> (btw, the print menuitem should be first with default="true")
5-second-fix.

I don't know what to do about the tooltips though. That's a XUL bug. It happens
on the back and forward dropdown menu, and SeaMonkey's print dropdown menu as well.
Even better: Let a tooltip from a different button display, then quickly open
the dropdown before the tooltip of the print button appears. Result: The tooltip
of the other button is displayed.

Workarounds:
1. Add tooltiptext="" to each dropdown menuitem. It doesn't display "Print this
page" anymore, but " ", i.e. an empty box. Looks terrible.
2. Remove the tooltip from the print button. That's inconsistent with the other
buttons.
3. Add appropriate tooltiptexts to the dropdown menuitems. That's the best I
have to offer right now.

I'm not able to hack button.xml, popup.xml or whatever.

Comment 20

[Steffen Wilberg]

Bug 147670 is the bug we need to fix.

Comment 21

[Steffen Wilberg]

Attachment: print menuitem is first with default="true"

> (btw, the print menuitem should be first with default="true")
This is the only change in this patch.

Comment 22

[Steffen Wilberg]

Comment on attachment 137370 [details] [diff] [review]
print menuitem is first with default="true"

Hopefully the final patch. Should be fine once bug 147670 is fixed.

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

-> 0.9

Comment 24

[José Jeria]

*** Bug 231085 has been marked as a duplicate of this bug. ***

Comment 25

[Steffen Wilberg]

Comment on attachment 137370 [details] [diff] [review]
print menuitem is first with default="true"

Slightly bitrotten.

Comment 26

[Steffen Wilberg]

I'll add a new patch once bug 147670 is fixed.

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

No, I think this is one of Seamonkey's misadventures. The print button is
intended as a convenience for a common action - print... having the more
advanced functions there does not make sense. 

Comment 28

[Vedran Miletic]

Then how about adding separate "Print preview" button? Would this be a better
solution?

Comment 29

[Doug]

(In reply to comment #28)
> Then how about adding separate "Print preview" button? Would this be a better
> solution?

I would like to second the motion for a separate Print Preview button. Printing
from web pages is a different experience than printing from other programs. Most
webpages are not formatted with printing in mind. 

I never print without previewing first to see if there is a reasonable print
stylesheet, or if there are 2-3 extra pages of junk at the end, or even if all
the information I want will be included on the printout (e.g., see Bug 150640,
Bug 154892, Bug 245887).

I don't know if it helps my case or not, but competing products include separate
Print Preview buttons as customization options. Hence, user-confusion is unlikely.

Would it help if I filed this as a separate enhancement request bug?

Comment 30

[Steffen Wilberg]

Sure, file a new bug about a print preview button. But don't expect something to
happen before 1.0.