Closed Bug 24221 Opened 25 years ago Closed 22 years ago

"Print" in context (right-click) menu

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(2 files)

Patch File adding print to context menu.\
735 bytes, patch
Details | Diff | Splinter Review
Patch File adding print to context menu.\
735 bytes, patch
Details | Diff | Splinter Review 
There should be an option to select Print when rightclicking on a webpage.
Depends on: 23567
Why?
Being able to right-click on a webpage and select print is really nice in frame. 
In 4.7 you have to click in the frame first the select File -> Print.
It's so much easier for the user to select print from a context menu.
IE also has it...:)

Sounds interesting enough to investigate. re-assign it to german since he owns 
the basic design of contex menu structure. Also set it for M16
Assignee: shuang → german
Target Milestone: M16
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
I just posted a patch for it. I don't know if we really need to put this in the 
build or not? I could post the whole file and then if you really wanted it you 
could just replace the file?
Oops, sorry. I accidently posted it twice, they are the same thing. is it 
possible for someone to deleat one of them?

I don't think Print is used often enough to deserve a place in the context menu. 
(Think: how many pages do you print in your average Mozilla session?)

Just because IE does it, doesn't mean it's a good idea.

It would be useful for printing frames, though.  Yeah, you can do "open frame 
in new window" first, but that isn't obvious and some sites prevent you from 
doing that using javascript.  

(the text would say "print frame" in that case, right?)
Specifying whether to print the current frame or the whole page is something that 
belongs in the Print dialog (or, failing native print dialog customization, in a 
`File' > `Print' submenu). It's still not common enough to deserve a place in the 
context menu.

Also, I can't be certain, but I'd say rerunning scripts when a frame is opened in 
a new window would probably be undesirable behavior anyway, i.e. a bug. So 
opening a frame in a new window for printing should work with no problems.

I have to agree with Matt: The context menus should not become the parking space
for all 'not so often used' functions, as they are meant to give you quick
access to the most commonly used stuff. I'd rather have the print menu item be
context sensitive, or even better (past this version) have a depiction of the
available frames in the dialog that users can select for printng.
Target Milestone: M16 → M20
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
So German, is this a WONTFIX then?

*** Bug 38270 has been marked as a duplicate of this bug. ***
Mark as WON'TFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Verified wontfix.
Status: RESOLVED → VERIFIED
*** Bug 38270 has been marked as a duplicate of this bug. ***
*** Bug 111272 has been marked as a duplicate of this bug. ***
*** Bug 109371 has been marked as a duplicate of this bug. ***
Why is this a WON'T FIX?

It is clearly useful, and SHOULD be a small change!
IE has print on the context menu, and I find that minor
feature useful!
I agree the other users, why is this WONTFIX?....  I find many other stupid
things included in the right click menu that are never used.

Also, this IS a feature that is used quite often.  People go to a webpage, get a
piece of info real quick and print it out - happens a lot around here.

Also, I don't know why some person came up with the idea of limiting the right
click menus.   I don't get very confused with long right click menus that I'm
familiar with like a browser.
*** Bug 112621 has been marked as a duplicate of this bug. ***
I now agree with mpt, this shouldn't be in the browser context menu.
Your right, this should not *just* be in the Browser context menu.
It should also be in the Mail & Newsgroups context menu, the Address
Book menu (just in case we want to print contact info), and in
the Composer context menu (so we can print the source).
i do a lot of printing of just single frames, specifically on pages where only
one frame contains pertinent information and i need to print just the single
frame for it to print right.  as others have said in this bug, it is something
that iexplorer has.  opera also has a frame context menu that pops up on
right-click within a frame, although it doesn't include a 'print frame' option.
 imho, frames are used often enough that a frame context menu would be
worthwhile.  within the context menu, a 'view frame source', 'view frame info',
'print frame', 'bookmark this frame', and more could be included.
Justification for this decision must be included in the bug report,
or I and many others will continue to reopen and request this feature.
It is not an unreasonable request, and unless I personally see proper
justification (which is not recorded here), I will keep raising this
issue.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
seems like a political decision to me - go and vote for it! i suggest replacing
"edit page in composer" by "print" - who needs to edit every web-page?? :-)
Personally, I think the concept behind the context menus in Mozilla is flawed.  
The current concept behind Mozilla's context menus is by making it shorter 
things can be found more quickly.  Well, that is not now I use context menus 
and I don't think other people use them that way either.  I do not read through 
the list of things every time.  For example, in Internet Explorer, I know what 
the word is that I'm looking for in the context menu and I already know where 
it is generally at.  So my eye goes immediately to the right place no matter 
how big the menu is or where it pops up - left or right side.
The problem I find in Mozilla, however, is the odd context names that I, nor 
anyone else is familiar with.  For example: "page info" instead of "properties."
So, I think
1. We should keep the context menu to names we already know.
2. We should include features in the menu that are helpful, not necessarily to 
keep it to say a limit of "7" things or whatever the number is.
3. The context menu should not shift and change for every page, thus letting 
the person mentially know everytime approximately where the feature is they 
want.  (Instead grey out like in Internet Explorer).
reassigning to Marlon. Cleaning up bugs for people who are no longer working on
the project (e.g. german). Will deal with this in context menu spec.
Assignee: german → marlon
Status: REOPENED → NEW
------- Additional Comment #10 From Jesse Ruderman 2000-04-13 12:07 -------
(the text would say "print frame" in that case, right?)

I would suggest that the text should simply say "print"
using "print frame" is needlessly complicated.  See my previous post about the 
flaws behind the context menu's in Mozilla.  In essence everyone who ever uses 
the feature is already familiar with the "print" command in a context menu and 
knows that right clicking in a certain frame will default to printing just 
that frame.
Looks like Print is in per the latest context menu spec. I am handling all this
work in bug 75338.  Having bugs open for each item isn't useful to anyone.
Marking as dup.

*** This bug has been marked as a duplicate of 75338 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
v dupe
Status: RESOLVED → VERIFIED
*** Bug 151311 has been marked as a duplicate of this bug. ***
*** Bug 152560 has been marked as a duplicate of this bug. ***
*** Bug 156077 has been marked as a duplicate of this bug. ***
*** Bug 165172 has been marked as a duplicate of this bug. ***
Every other item in the navigation toolbar is represented apart from print.
Seems like a bug to me.

How will a new Mozilla user print the contents of a popup window?
*** Bug 169268 has been marked as a duplicate of this bug. ***
Blocks: 157784
bug 75338 doesn't fix this.
Severity: normal → enhancement
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: print should be added to right click context → "Print" in context (right-click) menu
In that case, based on bug 75338 comment 210:
=========
the goal is to get back the familiar browser UI, what a user understands, if
he/she has needs to bookmark, send, save, print, etc.,  the only clear choice is
to place emphaisis on getting back the hidden contols they are familiar with.. 
not in expecting users to grasp some sort of new submerged user experience which
now takes place deep within an entire feature set replicated in context menus.
=========
...this is a WONTFIX.
Mozilla offers users NO EASY WAY to print the contents of a popup window which
has no nav bar. Surely a bug? 
Clearly, there is significant user demand for Print. Those advocating that
demonstrate that a.) it is a more intuitive and efficient means of printing
frames;  b.) it is useful for printing pages with hidden chrome (and more
efficient than restoring the chrome and then selecting the print from the pull
down menu); and c.) it is conditioned behavior for users of IE.

The only rationale for not including Print on the context menu is that "it makes
it too long and we don't want to duplicate that's already on a pull down menu"
(assuming that menu is available, which the latest direction of this bug affirms
it is not).

So, if for whatever reason, the size of the context menu must be fixed, I vote
that we eliminate View Page Source and/or View Page Info in favor of adding
Print Page/Frame. I use (or attempt to use) Print Page FAR FAR more often than I
view a page's source or info.

At the very least, add a user_pref so I can individually restore it.
>Mozilla offers users NO EASY WAY to print the contents of a popup window

ctrl+p

How is that intuitive?  There is no confidence that Ctrl+P will apply to the
popup window.  What's worse is that some popup windows go away as soon as you
click on
them.  You can't get focus, so you can't print them out.
>>Mozilla offers users NO EASY WAY to print the contents of a popup window
>ctrl+p

By this logic, there shouldn't be ANY context menus. Afterall,
Back = Alt-Left Arrow
Forward = Alt-Right Arrow
Reload = Ctrl-R
Stop = Esc
Bookmark = Ctrl-D
Save Page = Ctrl-S
View Page Source = Ctrl-U
View Page Info = Ctrl-I

Yet these functions are replicated on the context menu and, with respect to the
first five, in icon form on the toolbar. 

So why use context menus at all? We could even save costs and manufacture mice
with just one mouse button... The justification for context menus, even in light
of keyboard shortcuts is obvious: many users find such more useful than
remembering keyboard shortcuts and more efficient than moving the mouse the
distance to top level menu and navigating through menu options there...

Thus, we go back to functions used most often. And printing a page is more
commonly used than saving it or looking at its source or properties. Therefore,
Print Page/Frame should have precedence over any of these lesser used functions.
>There is no confidence that Ctrl+P will apply to the popup window.

_where else_ can it possibly apply to?
> Back = Alt-Left Arrow
> Forward = Alt-Right Arrow
> Reload = Ctrl-R
> Stop = Esc
> Bookmark = Ctrl-D
> Save Page = Ctrl-S
> View Page Source = Ctrl-U
> View Page Info = Ctrl-I

Except that print is used much more often.
>>There is no confidence that Ctrl+P will apply to the popup window.
>
>_where else_ can it possibly apply to?


The parent window that opened the popup.  And as I pointed out, some
popups are designed to close as soon as they are clicked on in any
form (perhaps even achieve focus) so that there is no way to print
the popup.
>Except that print is used much more often.

speak for yourself
OS: Windows 98 → All
QA Contact: mpt → sairuh
Hardware: PC → All
For myself and others I work with.
Does TalkBack provide any usage information?
arg. what a useless bug.

talkback provides:
reporter contact info
a url
a description from the reporter
stack traces for all threads
cpu details for the current thread

plus line numbers for the mozilla portions of the stacks.

each of these items alone is quite useful. I've actually found a bug using just
cpu details (actually it was the windows crash dialog, not even talkback). I've
fixed quite a few using just the last line from a stack trace. when those fail
we can ask the reporters for additional information. there's a feature to send
reporters information about bad builds (it hasn't been used much, but i think
we'll use it more in the future). we can find out if certain websites crash for
lots of people and focus more attention on them. we can also find out which
crashes happen a lot and focus more attention on them. there's even a threat of
backing out bad code (48hrs) if talkback shows a major jump and we can point to
a specific checkin.

yes talkback is good.

as for print in the context menu: no. even back is mostly not in the context
menu as are a bunch of other things.

what I can say is that we'll hopefully have a way to show the full menubar so
that you can use whatever items there are in it.  I suppose the best way would
be to allow it to behave as an autohide item where perhaps pressing <alt> for a
few seconds makes it hover (w/o reflowing the page) so that you can activate
whatever.
Assignee: marlon → blaker
Status: REOPENED → NEW
Component: User Interface Design → XP Apps: GUI Features
QA Contact: sairuh → paw
wontfix. no module owner has expressed any interest in accepting a fix for this.
if they do, they can reopen it. if you aren't a module owner then you should not
try to reopen it, it's bad karma. (blake [module peer] expressed a wontfix when
he resolved a bug as a dupe of this wontfix and expressed ambivalence when
someone's spec put it back)
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
How about if the bug is changed to
"Request for user_pref for right-click context menu item for Print"?
> wontfix. no module owner has expressed any interest in accepting a fix for this.
> if they do, they can reopen it. if you aren't a module owner then you should not
> try to reopen it, it's bad karma. (blake [module peer] expressed a wontfix when
> he resolved a bug as a dupe of this wontfix and expressed ambivalence when
> someone's spec put it back)

I have never seen anyone so resistant to a *reasonable* request.  What reason
beyond "I don't feel like listening to my users" or "I want to alienate as many
people as I can" is there for not implementing "Print" in a context menu?

The fact that there are patches that make it happen should tell you that there
is genuine interest.  There are also votes *for* this request.  What reason do
you have to marking this as "Wont Fix"?
recommendation: just do it

if mozilla was a large company you would invite ordinary users to test the gui,
record it on video-tape, watch it and analyze it - they would try to use it -
for sure. other large companies (whose browsers are much more in use at the
moment) already done these tests - so why not copy the good stuff ...

this bug just makes me realy @!?% %-/
I also think that it's a little ridiculous to refuse to implement a feature
that's  A. obviously wanted/needed, and B. apparently fairly simple to
implement.  However, instead of just spamming the bug with my rant about why
this should be done, let me just offer this....

A lot of people probably want this feature ( based on the number of duplicates
of this bug that have been filed ), and a patch exists which (almost) implements
the feature.  I'm going to assume that most people, when searching for a bug
before filing a new bug, do NOT include status RESOLVED in their query. 
Therefore, I propose re-opening this and assigning it to nobody@mozilla.org. 
This way, people who are searching for this bug will be able to find it a little
easier (which could cut down on the duplicates), and even if it won't ever be
fixed, at least those users who are technically savvy enough can apply the patch
that already exists to their own Mozilla setup by hand (as I did).

Ok, having said that; small rant:

And in case anybody is listening who cares, I REALLY think this feature should
be implemented in Mozilla.  To my notions, having a "right click print" feature
is pretty much the last way in which IE is superior to Mozilla in any regard.
*** Bug 189949 has been marked as a duplicate of this bug. ***
For anybody who cares, the patch provided with this bug has bit-rotted.  FYI,
the file to modify is no longer navigator.xul, but rather
content\communicator\contentAreaContextOverlay.xul, which is contained in
chrome\comm.jar in your mozilla install directory.

It appears that BrowserPrint() has now been changed to NSPrint() as well.

So, for anybody who wants to patch your Mozilla to add a print page feature to
your context menu, do this:

0. close any running Mozilla sessions

1. backup the previously mentioned comm.jar

2. extract the contents of the jar to a temp dir somewhere
 (make sure to extract the directory information as well)

3. edit the extracted contentAreaContextOverlay.xul and add the following lines:

           <menuitem id="context-print"
      		label="Print Page"
      		accesskey=""
		oncommand="NSPrint();" />

somewhere in with the other <menuitem> tags

4. rezip the entire extracted "content" subdirectory into a file named comm.jar

5. copy the new comm.jar (containing the edited contentAreaContextOverlay.xul)
into your chrome directory.

6. open Mozilla, you should now have a context menu option "Print Page" that
will invoke the print dialog.

-- provided as a public service to those who want this feature, and are willing
to hack their Mozilla install to add it --
*** Bug 203169 has been marked as a duplicate of this bug. ***
*** Bug 210840 has been marked as a duplicate of this bug. ***
*** Bug 224485 has been marked as a duplicate of this bug. ***
*** Bug 225456 has been marked as a duplicate of this bug. ***
*** Bug 230586 has been marked as a duplicate of this bug. ***
I'm relatively new to using bugzilla.  However I cannot believe what I have read
in this thread.  It defies belief for me to read fellow programmers arguing
AGAINST having a  "Print"  option in the right-click menu, particularly when IE
has one.  It's programmers like these that give IT DEPARTMENTS such a bad name
with end-users.

How can programmers forget the three most important tenets of computers for an
end-user :

1)  Being able to enter data
2)  Being able to have it processed accurately.
3)  The most important :  being able to output its
    results on screen or in print.

As a contributor has shown, it is possible to hack into Mozilla and provide a
PRINT option on the right-click menu.  It should not be so - it defies belief
that since 2000 there have been people at the core of Mozilla development
spending more time arguing AGAINST a PRINT option on the right-click menu than
simply providing it.

If IE can do it, Mozilla must be able to do it, as simple as that. 

Just like IE, just like Opera, Mozilla should be able to print ABSOLUTELY ANY
html page that it displays and which does not have restrictions, without exceptions.

It is when programmers show such lack of BASIC understanding of
user-friendliness that an otherwise better product loses out hands down to a
Microsoft product because there is one thing Microsoft does do well and that is
 BASIC UNDERSTANDING OF USER FRIENDLINESS.

I am in total shock and disbelief to see ANYONE argue against a PRINT option on
the right-click menu :  techies marvelling at one another in a world that has
nothing to do with the end-user !!

Ilka
BugMeNot is an extension that adds an item to the context menu. How hard is it
to tie an extension in to that and into the printing system? I would also like
to add a context-menu item when you select text and right-click on it: Print
Selection.
This is an excellent example of why the plugin architecture is a good idea.  The
Mozilla developers refuse to change this, but at least it is now easy to install
a plugin that will change it.

There is a plugin for Firefox called "Print", and it adds the Print command to
the right-click menu.

http://update.mozilla.org/extensions/moreinfo.php?id=162&vid=297

http://jeeradej.free.nnsol.com/mozdev/

Personally I think it is crazy to not have this by default.  When I teach people
how to use the right-click menu, I tell them that it is a short list of "the
commands that make sense" for whatever you are right-clicking on.  And the Print
command doesn't just make sense for a page, is a common thing to want to do!  It
looks like the major argument against this is "people don't really print too
often", but printing is common enough that there is a toolbar icon for it.

What really amazes me is that Firefox has "View Page Source" on the right-click
and NOT Print!  My wife is probably a typical user, and I'm not sure she has
ever done a "View Page Source" in Firefox.  But she prints something just about
every day: coupons, driving directions and maps, receipts, etc.

Mozilla developers: please reconsider this!  (Oh, and thanks for the work you do.)
(In reply to comment #50)
> >Except that print is used much more often.
> 
> speak for yourself

sheesh people i hate that this is won't fix its the dumbest thing ive ever seen
such an easy implementation for something so many want and its a wontfix!!!

its not bloat and its used a lot more often then the other context menu options
bet you he speaks for at least 10 times as many people then you and thats
probably a low number!!

i know its not that big of a deal but wontfixing this is so darn annoying!
*** Bug 267969 has been marked as a duplicate of this bug. ***
*** Bug 268229 has been marked as a duplicate of this bug. ***
Jeez, this is a lot of duplicates, I like #43 where it's added to about:config
so it's easy to re-enable.

(In reply to comment #15)
> *** Bug 38270 has been marked as a duplicate of this bug. ***

(In reply to comment #18)
> *** Bug 38270 has been marked as a duplicate of this bug. ***

(In reply to comment #19)
> *** Bug 111272 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> *** Bug 109371 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> *** Bug 112621 has been marked as a duplicate of this bug. ***

(In reply to comment #32)
> Looks like Print is in per the latest context menu spec.
> *** This bug has been marked as a duplicate of 75338 ***

(In reply to comment #34)
> *** Bug 151311 has been marked as a duplicate of this bug. ***

(In reply to comment #35)
> *** Bug 152560 has been marked as a duplicate of this bug. ***

(In reply to comment #36)
> *** Bug 156077 has been marked as a duplicate of this bug. ***

(In reply to comment #37)
> *** Bug 165172 has been marked as a duplicate of this bug. ***

(In reply to comment #39)
> *** Bug 169268 has been marked as a duplicate of this bug. ***

(In reply to comment #43)
> Clearly, there is significant user demand for Print.
> At the very least, add a user_pref so I can individually restore it.

(In reply to comment #58)
> *** Bug 189949 has been marked as a duplicate of this bug. ***

(In reply to comment #60)
> *** Bug 203169 has been marked as a duplicate of this bug. ***

(In reply to comment #61)
> *** Bug 210840 has been marked as a duplicate of this bug. ***

(In reply to comment #62)
> *** Bug 224485 has been marked as a duplicate of this bug. ***

(In reply to comment #63)
> *** Bug 225456 has been marked as a duplicate of this bug. ***

(In reply to comment #64)
> *** Bug 230586 has been marked as a duplicate of this bug. ***

(In reply to comment #69)
> *** Bug 267969 has been marked as a duplicate of this bug. ***

(In reply to comment #70)
> *** Bug 268229 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
*** Bug 271934 has been marked as a duplicate of this bug. ***
Component: XP Apps: GUI Features → UI Design
Agreed with #66. It would be good to have at least a “Print selection” (similar to the already present “View selection source”) context menu entry as, depending on the operating system, the “Print Selection Only” option is buried on a secondary tab of the print dialog and, apart for the impracticality of this location, most people even fail to notice it's there at all.
I've opened a similar bug for Firefox [0] (I didn't find a way to copy the bug directly to another project) for the “Print selection”-only issue. I really hope it eventually gets fixed...

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=497497
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: