Closed Bug 204519 Opened 21 years ago Closed 20 years ago

Add Print option to main context menu

Categories

(Firefox :: Menus, enhancement, P3)

Product:
Firefox
Component:
Menus
Platform:
x86
All
Type:
enhancement

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Firefox1.0

People

(Reporter: kentmail, Assigned: sipaq)

References

Details

Attachments

(3 files, 1 obsolete file)

Placement of the "print..." option on the context menu.
9.99 KB, image/png
Details
Place print somewhere else and cleanup whitespace
1.28 KB, patch
bugs
: approval-aviary-
Details | Diff | Splinter Review
"Print..." placement for menus that involved selected text.
2.06 KB, image/png
Details 
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 ?

For Mozilla, this is bug 24221.

Some similar bugs: bug 137014 (Mozilla) and bug 185239 (Firebird)
-> 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
Keywords: polish
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.
Here is the code of the the failed print button ("Print This") as well:

javascript:winopen('/dellstore/print_summary_details_popup.aspx?c=us&cs=04&kc=6W300&l=en&leadtime=3/26/2004&oc=dim24min&s=bsd&showleadtime=True&~lt=print','print','WIDTH=648,HEIGHT=510,RESIZABLE=YES,SCROLLBARS=YES,TOOLBAR=YES,LEFT=0,TOP=20');

All this does is open another popup window.

-RA
-> me
Assignee: firefox → bugzilla
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox0.9

    
  

        Attachment #144040 -
        Flags: review?(bugs)

    
    

    
  
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: 20 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.

    
    

    
  
As for other menu options being put into the context menu, none are really
needed like the print option:

File:
new window/tab - (can be done by using another window)
open file - (can be done from Windows Explorer or by using another window)
send page - (can just get the URL from Page info, then copy and paste the URL
into an email.  This feature is rarely used, thus extra steps are a little more
acceptable.)
work offline (can use another window to enable this)

Edit:
Find in this page - (this is not a context menu option in any program that I
know of; I use the keyboard shortcut for this option in every program including
firefox)

View:
Toolbars - (disabled by the pop-up; adding a context menu option just for this
would not be the best solution)
Statusbar - (rarely used; disabled by the pop-up; adding a context menu option
just for this would not be the best solution)
Text size - (can be modified before launching the pop-up)
Full Screen - (turning a pop-up into a fullscreen is kind of odd)

Go:
Home - (can open a new browser window for access)
History - (can use another browser window for access)

Tools:
Downloads - (can use another browser window for access)
Javascript Console, DOM Inspector - (both are developer tools, and thus the user
would know enough to copy the URL into a useable window; Because the user is
more technically inclined, the extra steps are a little more acceptable.)
Options - (can use another browser window for access)

File->Print: used commonly by a number of people, including e-commerce, banking,
and information gathering, thus extra steps to perform a print are not as
acceptable.  Also, many programs provide quick access to print via the mouse,
thus, it is prefered that Firefox also offer quick access via the mouse as well.

    
    

    
  
(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.

        Attachment #144040 -
        Flags: review?(bugs)

    
    

    
  
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

    
  

        Attachment #148928 -
        Flags: review?(bugs)

    
    

    
  


  
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

    
  
Flags: blocking0.9?

    
  
Flags: blocking0.9?
Flags: blocking-aviary1.0RC1+

    
    

    
  
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. 



    
  
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+

    
    

    
  
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? 

    
  

        Attachment #148928 -
        Flags: approval-aviary?

    
    

    
  
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 #59)
> 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.

For me this is lost functionality, not being able to print a single frame. There
is alreayd the option to only open a single frame via "/This frame/Show Only
This Frame". But how many end-users do you think will figure this one out? Also,
some websites use javascript to detect if they are in a frame or not, must I
also disable Javascript just to print one frame?


    
    

    
  
Hmm so there already is a show just this frame option.  Silly me the page I
viewed  and could not find it looked like it was in frames, but eviently it was not.

As for javascript that detects being in a frame and won't work if it isn't, such
a script probably will not print even in IE which has the right click context
menu for printing functionality because it effectively reloads the frame as if
it were in a seperate window to do the printing. It just does not display it.

    
    

    
  
(In reply to comment #61)
> As for javascript that detects being in a frame and won't work if it isn't, such
> a script probably will not print even in IE which has the right click context
> menu for printing functionality because it effectively reloads the frame as if
> it were in a seperate window to do the printing. It just does not display it.

You misunderstood what i said, what i mentioned about the Javascript what that
show only this frame sometimes doenst work due to scripts that checks if the
frame is not in the corret frameset. 
Anyway this hassle (show only this frame and the print) that no end-user will
understand anyway could be solved having a print option in the context-menu.

    
    

    
  
> You misunderstood what i said, what i mentioned about the Javascript what that
> show only this frame sometimes doenst work due to scripts that checks if the
> frame is not in the corret frameset. 

I think you misunderstood what I said.  I was saying that for those cases where
show only this frame does not work, print only this frame will most likely fail
for the same reason.

    
    

    
  
(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: 20 years ago → 20 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.

    
  
Flags: blocking-aviary1.0mac-
Keywords: polish

    
    

    
  
Comment on attachment 148928 [details] [diff] [review]
Place print somewhere else and cleanup whitespace

unsetting review request since this isn't going to happen.

        Attachment #148928 -
        Flags: review?(bugs)

    
    

    
  
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.

    
  
Blocks: 125824

    
    

    
  
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.

    
  
Blocks: 164421

    
    

    
  
*** 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. ***

    
  
No longer blocks: 164421

    
  
Blocks: 158464

    
    

    
  
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. ***

    
  
Blocks: majorbugs

    
  
No longer blocks: majorbugs

    
  
Blocks: 164421

    
    

    
  
*** 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.




    
  
Flags: blocking-aviary2.0+
Flags: blocking-aviary1.0mac-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-

    
    

    
  
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. :-)
Flags: blocking-firefox2?

    
    

    
  
*** 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.


    
  
QA Contact: bugzilla → menus

    
    

    
  
*** 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: