Closed Bug 204519 Opened 17 years ago Closed 16 years ago
Add Print option to main context menu
9.99 KB, image/png
1.28 KB, patch
|Details | Diff | Splinter Review|
2.06 KB, image/png
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030429 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030429 Mozilla Firebird/0.6 In IE, right-clicking on any page offers the user a Print option, an especially useful feature when you want to select text and then print the selection, or just make it easier to print without moving your mouse to the top of the page to click File-Print or the Printer radio button. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Do you want this for Mozilla or Firebird ?
Assignee: printing → blaker
Component: Printing → General
Product: Browser → Phoenix
QA Contact: sujay → asa
Version: Trunk → unspecified
Sorry about that - yes, Firebird. I'm not looking for only printing an iframe or a "Print Picture" option as in IE, but more of just a Print command on the context menu that opens the same dialogue window as File-Print or Ctrl-P.
Summary: Add Print option to main right-click menu (like IE) → Add Print option to main context menu (like IE)
How often do you actually print things whilst you're browsing? For me anyway it is at most a once-a-month event, not including printing from Adobe Acrobat or other plugins. It's simply not a frequently-performed enough action to warrant a place in the context menu (if it was, we'd not have any trees left in Canada...) Recommend WONTFIX. David, do you agree? OS --> All Component --> Menus
Component: General → Menus
OS: Windows 98 → All
I think it would be useful, but it should only print the current frame, just like IE. In a non-framed window, it should of course print the whole page. I often use the Print context menu when printing agreements etc. at work.
Confirming this bug as I have found no dupes. I vote for fixing this, along with the related bugs..
Status: UNCONFIRMED → NEW
Ever confirmed: true
"How often do you actually print things whilst you're browsing?" Actually, quite often, but it usually is only selected text on a page as opposed to the whole page. No need to print an entire page of graphics (banners, ads, title bars, and the like) if I only need a few paragraphs.
Yes, definitely fix this. I don't know about anybody else, but printing from within my browser is something I do nearly every day. RFC's, man pages, javadoc pages, and all sorts of stuff, I print from inside a browser. Not having this is a HUGE flaw in Mozilla, and this bug doesn't need to be carried over into the new Firebird browser. WONTFIX? Heck no, more like MUSTFIX.
I use print from the context menu as well. I too think it was a bad decision to leave this off of Mozilla just because some people incorrectly thought people didn't use it a lot. It would be useful if the print command was sensitive to whatever frame you click on with your context menu. This is the best useage of the print command (when there are frames). Since Sean Kent suggested that it should bring up the same dialog as File->Print, it should also default to "The selected frame" when frames are involved.
Hi there - just wondering if this option will receive any attention?
I don't think that they implement this but the developer must decide that..
Taking QA Contact as designated owner of Firebird-Menus. Sorry for bugspam.
QA Contact: asa → bugzilla
I would just like to justify some reasons why the print option may be more commonly used by some people. There are a number of people who use the internet as an information gathering source, and then take that information to use with them while away from the computer. Some examples include maps, bus schedules, plane schedules, train schedules, receipts of online transactions, price comparisons of products, and product information. In these, and many other examples, the user uses the internet and prints out a copy to use when they are away from the computer. In this case, printing becomes a much more common occurance while using a browser. The addition of "print" to the right click menu would provide an added benefit to users (including myself) as it has become quite a useful habbit from Internet Explorer. Also, without "print" in the context menu, one cannot print a pop-up window without resorting to a keyboard combination. This is sure to confuse the majority of people who do not know enough about computers to find the keyboard shortcut.
I've since learned that Chris Neale's Trivial extension adds a Print and Print Preview option to the context menu, but it also adds a lot of other stuff that now comes standard with the latest milestone and nightly builds (Cut, Copy, Paste buttons for example). As this whole extension is 23KB, would it not be a simple matter to just add a Print option to the context menu? Or will I have to learn to program and write this in myself? ;-)
I personally would never use this -- since most HTML is not pretty on the printed page, and I don't own a printer, I usually just save the page to my hard drive. But I have a suggestion, that there also be a "Print Selection" menu item added, similar to the "View Selection Source" item that would only print part of the page. As somebody else mentioned, there's no need to print pictures and stuff if you don't need them. The selection (if it's all text) could be sent to the printer as raw text, which would print quickly and easily.
*** Bug 228491 has been marked as a duplicate of this bug. ***
Would the polish keyword belong here?
I posted the comments below yesterday on Mozilla and someone emailed me back suggesting I post it here too. In addition to what I wrote yesterday I can only think that those who argue AGAINST the PRINT option in the right-click menu are people who never work in the real world : I am a consultant and in any company the one thing that frustrates and literally panics end-users the most, other than their PC simply not working, is their printer not working. As simple as that : if a business cannot print it is simply a disaster : invoices, letters, reports, and these days lots of stuff off the web, etc..., etc... I came to this issue because I was setting up an online service for an end-user and there were many help buttons throughout the setting up procedure. Pressing a help button would bring up a help popup Mozilla window with no menu. Most Help ran into two pages and I needed to print those help pages. Well, for the non-user oriented techies who argue against a PRINT option, I am a programmer myself, I know about Ctrl+P - I use it when I program, I am a computer consultant and work with computers every single day, yet I myself forgot about Ctrl+P. As simple as that. I right-clicked and could not find a PRINT option, so restarted the whole process with Internet Explorer. While in IE, I printed about 16 Help pages with the right-click menu - this is how useful that feature would be because 90% of end-users (not the techies here who incredibly recommend a WONTFIX) do not know about Ctrl+P. More to the point, I have seen countless times Netscape end-users taking a screen-print of a popup and pasting it into Microsoft Word because they had no PRINT option on the right-click menu. Did I miss the boat or aren't we trying to make Mozilla the BEST browser there is ? Can someone tell me soon so I know whether I should ditch Mozilla/Firebird and go to IE for all is problems ! My Mozilla post of yesterday follows -------------------------------------- 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 !! Here is the simplest test of all : show this entire thread to an end-user in any company and they won't believe that there are nerds out there arguing that it should be a WONTFIX ! And they will faint and later look at the Mozilla/Firebird community with disdain when they realise that this argument has been going on since 2000 !! Ilka
This bug hit me today when i had to print a pop-up confimation HTML page. I had to save the page to disk, then re-open it and print it. There was no menu bar no JS button to print. No Print in the right-click pop-menu? Give me a break.
Can we get this into the next major build of Firefox? (I would propose it, only I don't know how.) I suspect it would only take minimal effort to add this in.
*** Bug 237399 has been marked as a duplicate of this bug. ***
I would like to add a real world scenario. I also have come across this issue. (Missing "PRINT" option in R. CLICK menu options in a new window without menus.) http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=04&kc=6W300&l=en&oc=dim24min&s=bsd Try clicking the "Print Summary" button at the bottom of the page = POP UP WINDOW with NO PRINT OPTION, the PRINT button they have doesn't work... Thanks. I'm surprise more people have not come across this.
Assignee: firefox → bugzilla
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox0.9
How does this feature work with frames?
What's the point of this? Why isn't File->Print/Ctrl+P sufficient?
(In reply to comment #28) > What's the point of this? Why isn't File->Print/Ctrl+P sufficient? A print option in the context menu is easier to use and discover when the user is facing one of the following: 1. Windows without a menu bar. 2. Printing text selections. 3. Printing frames. Prog.
There are options for all of these in the Print dialog. We're not recreating the seamonkey context menu tower here. The arguments you made for windows without menus etc could be equally made of any other feature available through the menubar or toolbars on pages that disable them. Should we add context menu items for all those too? WONTFIX. Use an extension if you really want this UI.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
I've had the common experience on news sites when a pop-up window is presented and no menu bar to initiate a print. Same for some commerce sites. Having Print... from a context menu is often the only easy way to print -- also consider the non-tech-savvy user who is not going to find the key combo easy to remember.
(In reply to comment #30) > There are options for all of these in the Print dialog. We're not recreating the > seamonkey context menu tower here. The arguments you made for windows without > menus etc could be equally made of any other feature available through the > menubar or toolbars on pages that disable them. Should we add context menu items > for all those too? WONTFIX. Use an extension if you really want this UI. Wow Ben, when did this become the GoodgerFox browser? Should we just forget about all enhancements to the browser unless you like them? This bug has 8 votes, and consistently is brought up as a needed feature, yet for some reason you want to choose to ignore user requests. I find that attitude fairly narrow minded and insulting to the user community at large. It makes me question the $$ donation I gave through PayPal to this project. Why the hell should I share what limited resources I have when it is obvious that you don't seem to respect my or others' opinions for a simple enhancement? I've been an avid supporter of Phoenix, Firebird, and now Firefox, and converted at least a dozen people from using other browsers. We're not asking for a major change - we just want a damn Print button on the context menu! Why is this so hard to understand? For those that want this feature NOW, I've made a request to the custom builders to include it in their next builds. I also learned of an extension that someone wrote last week which adds the feature, get it here: http://extensionroom.mozdev.org/more-info/print
(In reply to comment #33) I don't mean to spam but I have to agree with Sean Kent on this one. A lot of features like this bug , porting the mozilla "sort bookmarks", inline autocomplete, etc. are being by the developers although people have requested those features.
If the reason for not adding this item to the context menu is the menu would be bloated, I'd say "View Background Image" is much less likely to be used than "Print" by most people. "View Page Info" is probably also much less used than "Print". If we're designing a browser that is supposed to be the best for most users, my recommendation is to remove "View Background Image" or "View Page Info" before rejecting "Print". Where I work, we were specifically instructed to right-click and select Print when printing out paper copies of contracts. If we were to change the browser to Firefox, most employees wouldn't know how to print anymore. Of course, people like myself could easily adapt, but I know quite a few of my colleagues would find it counter-intuitive. This is especially true when printing a specific frame.
I think this should definitely be added in. I, for one, will be including the above patch in my nightly builds when I release them.
Im reopening this bug, because - It has user high interrest - It would bring Firefox in alignment with other browsers - There are given valid "test-cases" where a it would be more userfrindly to have it, since the user have no other means of discovering that printing is possible see commment #29 - Ben, your argument about bloating the context menu may be valid, but the solution is not to block all additions to the context menu but to find the most usefull ones. IMHO Print is usefull, moreso than e.g. view background image. If the menu is bloated file a cleanup bug. - The assigned person has provided a patch and it is under review. Pulling the rug out under him like that is not acceptable IMHO. lets get this patch in.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
IMO, a compromise would be to make a print option only available on popup windows without a menubar.
Bug 69099 would be a better solution for menubarless windows, but would probably be harder to implement.
(In reply to comment #26) > Created an attachment (id=144040) > Hook up Print in the context-menu > Simon - bangbang023 has created a custom build using your patch, and it works perfectly. The build may be downloaded here: http://pryan.org/mozilla/firefox/bangbang023/Firefox_SSE2_O2_G7_20040319.exe Note - MSVCP71.dll and MSVCR71.dll must be added to the main folder, as bang forgot to include them in his build. I also don't want to bloat the context menu, but I agree with David Tenser - some commands on the context menu such as "View Background Image" are used far less often than "Print" by most people. In almost 3 years I've not once used the "Send Page" command either.
(In reply to comment #40) > some commands on the context menu such as "View Background Image" are used far > less often than "Print" by most people. In almost 3 years I've not once used the > "Send Page" command either. Ben Goodger probably considers "Send Page" as an important context menu entry: http://bugzilla.mozilla.org/show_bug.cgi?id=173954#c17 Prog.
FWIW, I often need "Copy page location".
Simon - Is someone scheduled to review the patch you created for this bug?
Comment on attachment 144040 [details] [diff] [review] Hook up Print in the context-menu Sean, no not at the moment. I will try to approach Ben about it again.
The patch submitted has not failed for me once yet and none of the users of my builds have complained about any bugs, so I hope this gets approved. It's more useful than other context menu items.
Jayfromtaiwan has implemented a build using this feature. Thus it has allowed me to test out this patch. I noticed one problem is that when highlighting some text on the page or some text within a textfield (like the comment field here on bugzilla), that the "print..." option appears as the first item on the list. This can cause some problems for users, since a text editing feature like cut or copy or undo it expected to be one of the first few items. Many times I would accidentally click the "print..." option because it was the first item, instead of the copy option. I propose that the patch move the "print..." option elsewhere on the menu. This would be more consistent with the context menu for the page and an image or link. Also, it would alleviate the problem of the user accidentally clicking the print option. I have uploaded an example of what I mean, and I showed just one of the many possible solutions that could be used. It suggests placing the "print..." option after the "select all" option similar to how IE handles it.
Thanks Kevin for your feedback. The print-context-menuitem is now placed above "select all" when text is highlighted on the page or in an input textfield. I also cleaned up some whitespaces. This is just a suggestion. Ben, if you decide to check this in, please place it whereever you want to.
Attachment #144040 - Attachment is obsolete: true
Thank you for considering the suggestion Simon. In the attachment I noted that my sugestion was one of many ways to implement the feature. I was hoping to get some feedback from some people on what might be considered the best place to put the "print..." option on the two menus. For example, I see 3 potentially good methods: 1) After "Select All" Pros: Undo, Cut, Copy, Paste, Delete, and Select All are all text editing options that are kept close together in most prorgrams. Thus, it may be practical to keep "print..." which is not a text editing option outside of this list (such as below "select all") In the menu where it only has "Copy" and "Select All" this keeps "print..." from separating the two and causing any confusion. Cons: For quick visual recognition (without reading much), some of the other methods might be easier for the user. 2) Before "Select All" Pros: When you bring up the context menu from a textfield (like the comment form here on bugzilla) this menu places the "Print..." option right above the horizontal separator. This is consistent with the page menu and links menu, which places the "print..." option just above a horizonal separator. Such consistency would allow the user to visually find the "print..." option in any menu quicker (with less reading or searching). Cons: The only problem is that the horizontal separator idea does not apply to the menu for text on the page (when you hight some page text and right click). Also, it does mix text editing options with "print..." which may or may not cause a problem?? 3) Just before the horizontal separator. Pros: As describe earlier, by having "print..." just before a horizonatal seprator in every single menu, this would allow the user to quickly remember where the option is visually. This would cause his eye to jump to the location quicker in each menu because of the consistency. Cons: In order to do this, in one menu "print..." would have to go before "select all" and in another menuu, "print..." would have to go after select all. This would break the consistency of the order of items between the two menus, and thus this option is probably not recommended. ----- I know this is a small issue to give such large consideration to. It's good to just have the print option in the menu now. However, I would like to cover every little detail (get it polished up just right before it's implemented). I personally, prefer method #1 and it is kind of the reason that I am posting. However, I hope to hear back from others if you might think the others would work betting in using the menu. Note: I have attached a screenshot that might be useful in comparing the two. (If you want to visualize what #3 would look like, open up Attachment 148903 [details], and then open up the new screenshot I have attached here and see how "print..." looks when it is placed above the horizontal separator on all the menus.)
Thanks for writing up these options, Kevin. Personally, I have no preference about where Print shows up on the context menus. I would just like to see it included. If I had to vote, I would add it in just above "Select All". Thanks to several custom builders now including this patch into their nightly builds, I am able to use Print from the context menu on a regular basis. It would really be nice to have it added to the official builds. This bug now has 31 votes - any chance of getting it checked in before 0.9?
*** Bug 245847 has been marked as a duplicate of this bug. ***
Priority: P1 → P3
Target Milestone: Firefox0.9 → Firefox1.0
Is this bug now fixed and included in the code? See Peter6's post for more.
with the latest nightlies, the patch does not seem to apply for me. It just does nothing.
Sorry Christopher, but I can still cleanly apply the patch both to the trunk and to the aviary-branch. Be aware that the file browser-context.inc is not present in the nightly builds. It is a part of the browser.xul file. When I apply the patch to the browser.xul file by hand it also works.
Status: REOPENED → ASSIGNED
Flags: blocking-aviary1.0RC1- → blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
This sounds like all the pieces are in place. Can't it just get checked in, verified, and approved already? Sick of looking for builds with this fix "patched" into it. Thanks.
(In reply to comment #53) > Sorry Christopher, but I can still cleanly apply the patch both to the trunk and > to the aviary-branch. Be aware that the file browser-context.inc is not present > in the nightly builds. It is a part of the browser.xul file. > > When I apply the patch to the browser.xul file by hand it also works. How would I apply it to that file then?
add the lines by hand
Comment on attachment 148928 [details] [diff] [review] Place print somewhere else and cleanup whitespace I don't think there's agreement yet that we even want this.
Attachment #148928 - Flags: approval-aviary? → approval-aviary-
(In reply to comment #57) > (From update of attachment 148928 [details] [diff] [review]) > I don't think there's agreement yet that we even want this. > Is this the print option just for textboxes or selected text on the page as well? I'm guessing it's just for textboxes.... I don't have any grand arguments for why this may or may not be good to have, however here's a few notes that might help in some way. I think the benefit of this might be related to having the ability to print selected text on a page (which I oddly enough found to be useful, even after just having the feature for a short time). Since the user might have something they want to print that happens to be in a textfield instead of the page text itself, this might help. I suppose another benefit is that it might give a little more consistency among the context menus (which is important for finding items quicker). On the other hand, IE (which normally has consistent context menus) does not have this feature for textboxes. As for the issue of context clutter, it's possible that proper positioning in the context menu, as well as the consistency among the menus might help alleviate some of the problems.
re comment #57. I agree this should not be a 1.0 blocker because: 1. It is a new feature 2. It adds context menu items which would need to be localized. 3. You can print with File -> Print or Ctrl+P, exactly how many methods do we need? That said, What is useful about a context print menu is the ability to print a single frame. So you can print the content frame without having to waste ink/toner on all the ads and other page clutter. What I think would be much more useful would be a context menu item on frames to display the frame alone in the window. Then you could view it as it will print and print just the one frame using the already supported interfaces.
(In reply to comment #57) > (From update of attachment 148928 [details] [diff] [review]) > I don't think there's agreement yet that we even want this. Ben, exactly who is "we"? If by "we" you mean you and the other devs, I would point you to the 44 votes supporting this request. Out of over 800 FF bugs with at least 1 vote, it ranks #16! Not to mention that most of the 3rd party builders are now including this patch because they agree it adds value. So what exactly is the controversy? We are talking about adding a few lines of code, which will provide a feature that a LOT of users want. We have had a working patch for 2 months at this point - what is the harm in checking it in?
Summary: Add Print option to main context menu (like IE) → Add Print option to main context menu
(In reply to comment #64) I have to agree. As someone who wants Firefox to the point where I can talk my organization, a University with 30,000+ students, into switching browsers ASAP, I see this as not only a simple decision, but an essential one. I know there is value in keeping Firefox lean and mean but if you don't pay serious attention to basic features that average users employ so much they take them for granted in other browsers, how do you expect to get organizations to switch?
Dare I suggest that bug 216292 would actually be more suitable? The context menu is already quite heavy whereas the toolbar is light. Most of this target audience we are supposedly targeting are going to look for a big print button before right clicking on a page. I'd never think of right clicking before File, Print.
We = me, myself and I ;-D although I asked blake, asa and dbaron and they all tended to agree, I think. Click in the frame, and click print.
Not gonna happen. Make an extension.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
Hold on here. What about pop-up windows that DON'T HAVE a menu bar? the right-click pop-up menu is the ONLY WAY to print the window.
And for anyone making the "It's got n votes argument," it's worth keeping in mind that there are over 60,000 people that have Bugzilla activity (and so every opportunity to vote for any bug). That would mean this bug has the support of approximately 0.073% of Bugzilla users. Then it's worth noting that Bugzilla users are approximately 60,000 of the most advanced users of the 740,000,000 people connected to the web. That certainly isn't much of a case for real support.
Comment on attachment 148928 [details] [diff] [review] Place print somewhere else and cleanup whitespace unsetting review request since this isn't going to happen.
What about he community of non-developer, non-geek users that we're trying to build Mozilla/Firefox for? Their voices are not here. Who is the advocate for the "customer" not just the developer community which is a fraction of the userbase. I for on introduce Mozilla/Firefox to as many non-technical users as I can and ease-of-use is very important to most of them who are not as adaptable as the dev comminity is. Or I be could be wrong and we're just wasting our time on this to make ourselves feel better becasue we can sling code for the sake of it.
lophat, don't get melodramatic and misleading. Of course the menubar isn't the ONLY WAY to print. How about ctrl+p? (Or even more exotic methods like grabbing the URL from page info and loading that in a browser -- just to show that your suggestion that it's the ONLY WAY is a completely bogus suggestion.) Should we reproduce every menu item on the context menu because it's not available in pop-ups? No. That'd be just silly. We already have a bug on file (or should) for a context menu or shortcut to show the entire menubar in pop-up windows. That would be a sufficient workaround (beyond the already sufficient keyboard shortcut) for this problem. Suggesting that a context menu is the ONLY WAY to print the contents of a pop-up is disingenuous and accomplishes nothing in forwarding the argument for this change.
OK, what's the work-around for a non-technical user who's faced with a pop-up or intentionallt JS opened window which has no menu bar, to select print?
lohphat, you're right, the end user isn't represented in those 44 votes and that's another good reason not to pay them much notice. That you've helped new end users get going with Firefox is great, but it doesn't make you (or even me - I've converted people too) a usability expert or any kind of representative of what traditional end users want or need. This is going nowhere and unless you can produce some pretty convincing usability data or HIG docs, this isn't going to happen for Firefox.
Status: RESOLVED → VERIFIED
You've not seen me melodramatic. ask leaf ;-) Think of the non-techy user, like Grandma, not another code geek who has no problem copying/pasting URLs from page info screens. If we're to attract more people to the product keeping the UI deltas to a minimum is a priority. In IE 1. Go to http://www.sfgate.com 2. Click on the Day in Pictures link. 3. It throws a new JS window. 4. Right click in the window -- oh look - "Print..." This is not a "can you do it another way" issue but a "should you force the user to do it in a non-obvious way" issue. Printing is a common action -- which the contect menus are for in the first place, not to list every feature on the menubar.
Believe me I'm not crippled by this but am the messenger for many who are. You, me, and the other developers are higer-than-average in deductive reasoning -- most of the population is crippled by things like this. Wonder why BOFH is popular? Because it's true -- moust computer *users* do not possess the skills to workaround issues like this without calling for help. "How do I print this? There's no menu and the context menu won't let me." The average user is not going to give a *&^*&% about View Page Source or Info. Trust me on that. The vote count is important -- you can't judge 43 votes by the entire dev base of 60,000, but on the ration of the voting subset. If you look at all votes for WONTFIX bugs, this bug is 4th from the top exceeded only by bugs with 51, 52, and 144 votes. All the others were low single digits. In that adjusted scale, this bug is important.
I have no clue why, in the hell, this one was turned down. Surely "view background image" is a lot less useful than something people actually use.
Please stop lamenting about the WONTFIX decision in this bug. The devs have decided (for the second time), and although I do not agree with them in this matter, it won't do anything good and Ben and Co. won't change their mind in this matter. Nevertheless I will try to update the patch as long as I'm able to do that. And if someone wants to do an extension based on the patch, he/she is free to do so.
(In reply to comment #76) ... > This is not a "can you do it another way" issue but a "should you force the user > to do it in a non-obvious way" issue. > > Printing is a common action -- which the contect menus are for in the first > place, not to list every feature on the menubar. I've got to agree with these two points. It is a commonly done thing, and intuitive to everyone. Plus, it saves a lot of mouseing on larger monitors. For those who, like me, have bad wrists, it is nice.
Mozilla.se help forums are now receiving end user complaints about the lack of this feature. As for the 0.073% of all users argument, that's quite bs. What matters is where it ranks among other bugs, and it ranks high. If you're going to use that kind of arguments then *ALL* bugs probably rank below 0.1%, and thus all votes should be ignored. As for end users... well, we're now getting complaints from people who find this feture invaluable.
Mikael, The behaviour of the Mozilla programmers on this issue is nothing short of shocking. Look at my post of 2004-1-11 in this same thread (#19), 9 whole months ago. The Mozilla programmers have spent more time and energy arguing AGAINST this feature which so many people want, than they would have needed to simply IMPLEMENT it ! 1 whole year of arguing against it. It's shocking lack of understanding of user-friendliness. As a programmer myself, with software I have written and which is used worldwide, I lose total respect for the programmers behind this. How can one respect a programmer who will spend more than 5 seconds deliberating on whether a PRINT OPTION should be available on the right-click menu !!!!!? Out of all issues, I find this one the most mind-numbingly shocking. ONE WHOLE YEAR DEBATING THIS - it is ridiculous and all those who have argued AGAINST it should be ashamed of themselves as they give all programmers a bad name (people living in their own world which has nothing to do with reality!). Ilka
please take your advocacy comments to the forums at mozillazine. Further complaints in wontfixed bugs is an abuse of your bugzilla account. Every useless comment added to this bug makes searching bugzilla that much more difficult. Please stop. Now.
Right. There is now a forum thread about this issue: http://forums.mozillazine.org/viewtopic.php?p=772377
*** Bug 258412 has been marked as a duplicate of this bug. ***
Ben - So you will approve <a href=https://bugzilla.mozilla.org/show_bug.cgi?id=256218>Bug 256218</a>, adding the Go button to the default toolbar because IE users expect it, but you still refuse to add Print to the context menu? Wasn't your argument against 204519 that users could just do Ctrl+P? Well users can also add the Go button to the toolbar using View->Toolbars->Customize. And guess what? IE users will also expect Print on the context menu, because that is what I came to depend on before I switched from IE several years ago. So why not approve this bug already?!?
Sean, this bug has been marked WONFIX. If you desperately need that feature, make or find an extension. Stop spamming resolved bugs with advocacy comments. Please read comment #83 and only comment further if you don't value your Bugzilla account.
(In reply to comment #87) > Please read comment #83 and only comment further if you don't value your > Bugzilla account. Bah. I've had it with this. Sure enough about not commenting, but this "i'll scare you to silence" business is FUBAR. BE CIVIL about it for crist's sake! Note that i've respected your wishes by taking this to the forum thread, which i'm quite sure you've ignored. But if you can't even have the decency to not include threats in your posts, I'll answer in your style. Thought never comes up when the situation "me against the community" arises that maybe you should reconsider, did it? And silencing people is not helping. That searching bugzilla would be made harder by people talking about a bug (which you wont fix, but a bug nonetheless) is just a bit too much of a Stalin explanation for my taste. So go ahead, if you feel like it, and drop my bugzilla account. You will in that instant also terminate my entire work with Mozilla, which would include the entire swedish localization. You get the honor of explaining that to the community if thats the choice you make; and perhaps you should consider things twice before you start shutting people out of working with mozilla applications just because they don't agree with you. Who knows, you may even get to be in a press release printed in newspapers over here. Wouldn't that be fun? Good PR for mozilla and all. I would, however, much prefer a development climate where we dont resort to terrorist tactics to silence people. We could all just ask nicely instead of making threats and behaving like adolescents.
Mikael Hedberg, bugzilla, especially wontfixed bugs, is not the appropriate forum for this. Take it to email or the newsgroups or the forums. Every advocacy rant posted in bugzilla makes finding and addressing real problems in this database that much more difficult. Bugzilla is _not_ an advocacy forum. Abusing our development tools only hurts the project. If you care about the projects as much as your involvement suggests, then please use the appropriate forums and stop devaluing our bug tracking tool.
(In reply to comment #89) If I thought it was, it'd be quite unlikely that I'd start a forum thread about it, woudln't it? And I'm sure that you'd have read I was aware of this, if you read my post. However, that doesn't mean you can go around threatening people and being rude about it. Shutting developers out of the development tools because they posted once too much in a wontfix bug hurts the project as well. So maybe if you care about the project like your involvement shows you can try to be a bit nice about it, hm? Ask nicely, so to speak? "Please" is good for communication, "if you value your bugzilla account" is not. If you don't want to spam bugzilla, you could even have sent a nice email instead of a threatening bug comment. But enough said about that. And if you do have something else to say about it, please do email me instead.
This has already been said many times, but this time, I'm speaking for many friends who are not as technically inclined as I, or anybody else on Bugzilla, for that matter, am. This lack of a print optioon on a context menu is, depending on the user, anywhere from a sticking point to a crippling feature. Simply because 4 devs on the project don't want to take their valuable time and spend 1 minute of it to add a feature that has been pverwhelmingly voted for, is coompletely irrational. It seems that Ben Goodger has an ego problem. He started out against it, and he's not going to tarnish his ego by admidtting that he's wrong. This is not the way to run a software project. Secondly, about the fact that .073% of all bugzilla users voted on this. Of that .073% of users, all of them barring 2 have voted for it. The rest either have not seen this, they don't use firefox (maybe because of this), or they just haven't responded yet (maybe because they're scared to lose their bugzilla accounts). We shouldn't need to get an extension to add this major feature. If anybody would like to speak to me personally about this, e-mail me. But Ben, Don't let your ego get into this. An open source project is no place for a huge ego. It's a place for people to get good software that works the way that THEY want it. Note that I said THEY, not THE DEVELOPERS.
I've been using bangbang's custom build with this patch added for ages now. I've come to rely on the print option on the context menu. I didnt realise it wasnt standard until now. Having read the looooooong debate it does look like the developers are being very stubborn.
I am seeing the print option in this build. Is it now in the trunk, or is it put in just by this builder? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041213 Firefox/1.0+ (MOOX M3) I found it at http://www.moox.ws/ Thanks.
(In reply to comment #93) > I am seeing the print option in this build. Is it now in the trunk, or is it > put in just by this builder? Please ask the builder before asking here. Bugzilla is for issues with *official* builds (not unofficial builds, unless the issue exists in both), and I'm sure your builder can answer that question better than we can anyway.
*** Bug 276939 has been marked as a duplicate of this bug. ***
I voted for adding "Print Frame" in the context menu. I'd use it for printing my bank transactions that appear in a separate frame. With Firefox 1.0 (downloaded 10th Jan, 2005 from mozilla.org) I get 3 pages, one for each frame. Please consider adding this feat in the main Firefox release.
*** Bug 279311 has been marked as a duplicate of this bug. ***
Especially when using pop-up forms on my corporate intranet sites. Don't need Canadian forrest, Acrobat pdf witer printer does the job very well... Found a MOOX M3 not Mozilla group supported beta version of Firefox, which includes the printing option. GREAT! (In reply to comment #5) > How often do you actually print things whilst you're browsing? For me anyway it > is at most a once-a-month event, not including printing from Adobe Acrobat or > other plugins. It's simply not a frequently-performed enough action to warrant a > place in the context menu (if it was, we'd not have any trees left in Canada...) > Recommend WONTFIX. > David, do you agree? > OS --> All > Component --> Menus
*** Bug 281082 has been marked as a duplicate of this bug. ***
Given the freeware roots of Mozilla/Firefox I can understand how some key people seem to think that real men never print. I guess they never made an online purchase of software. But if the excuse for not implementing is that there is already a ctrl-P hot key, should there not be an urgency to document this when one looks up "print" or "print frame" in the help menu system.
*** Bug 283849 has been marked as a duplicate of this bug. ***
Finally I found suitable extensions on mozilla.org <a href="extensions/moreinfo.php?id=282">Print It!</a> <a href="extensions/moreinfo.php?id=162">Print</a>
*** Bug 294923 has been marked as a duplicate of this bug. ***
*** Bug 295944 has been marked as a duplicate of this bug. ***
*** Bug 295944 has been marked as a duplicate of this bug. ***
Congratulations! Two years of debating and no reaction. Why is it so difficult to add this simple thing into an official release? There is no reason to show up the pros and cons again. This feature is a MUSTHAVE! You have 60 Votes for this report. You have at least 10 related or duplicated reports. And you don't know how many non English speaking or shy people did not express their wishes. Please do it. Please.
(In reply to comment #106) Amen.
*** Bug 301974 has been marked as a duplicate of this bug. ***
*** Bug 305401 has been marked as a duplicate of this bug. ***
I just read through this thread, and this is seriously Kafkaish. Is there any argument against fixing this other than "It has ben marked WONTFIX, so it won't be fixed"? I recently introduced Firefox to my father, and he soon got stuck on printing from a popup. This was the result of a form sent by POST, so copying the URL was not an option. Neither of us thought of Ctrl+P. (Hey, ask any user interface expert what he thinks of having a function only available as a keyboard shortcut.) Remaining was to save the page to disk and open in an other window. Not very impressing.
This is the most absurd bug discussion I've ever read. Why will the developers not admit that this is simply a feature the user expects to be there? As others have pointed out, the right-click menu is the only way to print a popup menu without requiring external knowledge of the shortcut keys. And it's so trivial to fix. What is the downside to having a Print option in the context menu?
If you don't add this to the context menu, IE wins for "easier to use interface". period.
Asa just removed himself from the bug email reports. I just don't understand the decision behind this. There's a reason people requested that I include the patch in my daily builds.
Why not post 2 versions of the build - one with the right click context abililty to print a frame, and one without. Then people can vote via their downloads.
Wonderfull example of Open Source NOT working. There is customer demand from the targeted audience for a certain function (printing a page, which btw also allows printing to pdf, which is a very convenient way to archive a page), but instead the developers provide functions only a very small part of the targeted audience would use. Who would think of Ctrl-P, the equivalent for a menu option, if there is no menu? Then of course, a window without a menu is horrible by itself, as it leaves users without visible access to important functions. Requiring a user to use a context menu for BASIC functionality such as printing or otherwise saving a page is already bad design. But it is still better than requiring the user to use a keyboard shortcut (shortcut to what? it is no shortcut if there is no alternative) without giving a clue that the function might exist! Read some Apple Human Interface Guidelines if you still disagree... (btw. on Mac OS there typically IS a menu bar, even for pop-up windows - but even there Print would make sense in the context menu, especially for printing a single frame)
You have a point there Sjoerd. Maybe the right solution is to show the menu bar even om popups. (Not the navigation field, that's available from the menu). After all, a function available only on a context menu is bad UI design too. (but not even close to keybord combination only). Any arguments against? In practice this could be implemented by assuming menubar=yes, if the menubar feature is not specified by the webpage. Currently menubar=no seems to be assumed. An even more radical option would be show the menu bar even if the webpage requests to have it disabled. That is, make dom.disable_window_open_feature.menubar default. Print in the context menu would still be useful for printing currect frame or selection, but the worst problem would be fixed.
Just to add another point: Context menu in thunderbird has both a Print and a Print Preview menu option.
(In reply to comment #117) > Just to add another point: Context menu in thunderbird has both a Print and a > Print Preview menu option. Did it ever occure to the allmighty maintainers of the source that perhaps the contents of the context menu should be decided by the *USER* ? Why not just make it an *option* ? after all isn't that what open source is about? The simple fact that this debacle continues is an embarrasment to the open source camp. Numerous people (read: USERS) have expressed a desire for this feature. Numerous others have expressed a desire for this feature on the behalf of others who for what ever reason cannot speak here for themeselves. The pigheaded stubborness that keeps this bug as a firm "WONTFIX" is blatantly an EGO issue and should not be allowed to permeate the DEVELOPMENT process. Ben/Asa, get your heads out of the sand and look around. Enough people want this (and the case has been made well, assuming you bother to read this thread or the forum thread (http://forums.mozillazine.org/viewtopic.php?p=772377) since you DICTATED WONTFIX) that it should AT LEAST be made the users option to be there. Quite frankly the majority of the context menu should be at the users whim to change and modify. It's a disgrace that so many people (read: USERS) are forced to BEG for this item to receive attention and the powers that be have FLATLY DENIED THEM ANY ACCOMODATION. This is a point blank testament to the FAILURE of Open Source's and the distributed development model's ability to compete with proprietary trash like Windows. Either be responsive to users or pass the torch to someone who will. If Asa would like to terminate my account now for expressing an opinion, be my guest (see comment #87). But not before I re-iterate this sentiment: Non-technical users (the ones that make up about 80-90% of the computer using public) are paused if not stumped when faced with this OMISSION. And they are not represented here because most of them can't or won't even FIND bugzilla, let alone figure out how to use it. Period. this bug tracking system is NOT simple enough for the average user. It's actually QUITE DAUNTING so don't look for them to comment here. Mozillazine is also well beyond my girlfriend's and especially my mother's attention span or care span for that matter. They just fire up IE because - surprise! "it works". Their voices are not represented here. Neither are the voices of any of my clients. They vote with their desktop icons, and all too often they are voting for the little blue 'e' because they are able to get their work done. To them firefox is the obstacle. In this instance they are right. Get this thing into production. Make it an option settable by the user (I'll set if for them). In fact let me the user decide for myself what I want on my context bar and you won't have to worry your pretty little heads about it. And fwiw, an extension isn't an option since extensions break every time the browser is upgraded. Very not acceptable and certainly an abomination in a business environment.
WONTFIX bugs aren't likely to block any release. :-) Also, only peers should touch the blocking +/- flags, non-peers should nominate (?) only.
Flags: blocking-aviary2.0+ → blocking-aviary2.0-
So why did you - it yourself?
Flags: blocking-aviary2.0- → blocking-aviary2.0?
(In reply to comment #120) > So why did you - it yourself? Meant to clear the flag, not - it. oops. :-)
*** Bug 323177 has been marked as a duplicate of this bug. ***
*** Bug 332726 has been marked as a duplicate of this bug. ***
I just ran into the limitations of this Firefox software here: How do I determine my phone Phone Software version? (http://idenphones.motorola.com/iden/support/software/html/firmware_utility.html#) There is no way to print this window from Firefox. The only thing I could do was to open it in IE (7, in this case). Please reopen this bug and fix it, especially since a patch exists.
(In reply to comment #124) > > There is no way to print this window from Firefox. The only thing I could do > was to open it in IE (7, in this case). > If they reply, I'd bet that they'll ask you to use Ctrl+P.
*** Bug 266505 has been marked as a duplicate of this bug. ***
(In reply to comment #125) > (In reply to comment #124) > > > > There is no way to print this window from Firefox. The only thing I could do > > was to open it in IE (7, in this case). > > > > If they reply, I'd bet that they'll ask you to use Ctrl+P. > There is an extension for this https://addons.mozilla.org/firefox/162/ Yes, it is an option. Everyone can be happy now :)
(In reply to comment #2) > For Mozilla, this is bug 24221. > > Some similar bugs: bug 137014 (Mozilla) and bug 185239 (Firebird) Note that bug 185239 was just recently fixed.
You need to log in before you can comment on or make changes to this bug.