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: 25 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: 25 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: