Print on the Firefox context menu
Mikel Ward
I had a situation today in Firefox where an online payment popped up in
a new window without the usual tool bar or menu bar. I wanted to print
the payment receipt, but the Print button on the tool bar obviously
wasn't available. (There was a Print button inside the page that used
JavaScript to print the page, but it didn't work in Firefox.)
The next thing I tried was to right click inside the window to use the
Print context menu item, but Firefox doesn't give me one. Both
Thunderbird and Internet Explorer have it, and to me it seems like a
logical place for it to be. I had to search Bugzilla to find out why
this wasn't available in Firefox.
There is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=204519)
with 83 votes requesting this feature, but it's been WONTFIXed.
Ben believes users should use Ctrl-P, but many users won't know there
is such a keyboard shortcut, and some users will prefer to use the
mouse where possible. I don't think we should regard keyboard-only as
a solution for a common task. (Ben, would you mind elaborating here?)
I also found some discussion in this newsgroup in early June where
Gervase believes the ideal solution is to add a context menu item to
show the menu bar if it's hidden
(https://bugzilla.mozilla.org/show_bug.cgi?id=69099).
By this logic, however, there would be no items on the context menu at
all. Print belongs there just as much as Back, Reload, Send Link, View
Page Source, of any other the other items: they are all actions that
can be performed on page.
I can't understand why the simplest and most obvious solution is being
ignored, in spite of the huge demand and need for it.
There have been a lot of comments and complaints in Bugzilla, but devs
have rightly asked people to move the discussion to the news groups.
I would welcome some discussion and debate on this before it is
rejected.
Myk Melez
> I also found some discussion in this newsgroup in early June where
> Gervase believes the ideal solution is to add a context menu item to
> show the menu bar if it's hidden
> (https://bugzilla.mozilla.org/show_bug.cgi?id=69099).
That's not a bad idea. Another possibility would be to insert a
twistie, splitter, or other minimal (but visible) UI into the window by
means of which the menu/toolbar could be made visible. That'd be more
discoverable than a context menu item.
> By this logic, however, there would be no items on the context menu at
> all.
Sure, whether to have a context menu item is orthogonal to whether to
include a mechanism for making the menu/toolbar visible again. We might
do either, both, or neither.
-myk
ehume
Mikel Ward wrote:
> The next thing I tried was to right click inside the window to use the
> Print context menu item, but Firefox doesn't give me one. Both
> Thunderbird and Internet Explorer have it, and to me it seems like a
> logical place for it to be. I had to search Bugzilla to find out why
> this wasn't available in Firefox.
>
> There is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=204519)
> with 83 votes requesting this feature, but it's been WONTFIXed.
>
Currently I am very satisfied with PrintIt. Some of my themes
(SphereGnome, ColorGnome, CloudGnome and HiVisGnome) have menuitem
icons, and in those I make sure that most oof the context print
menuitems are skinned.
The other problem you are having is with menu-less popup windows. I
have my browser set up too disallow diabling of menubars, fixed window
sizes and scrollbars. In other words, all popup windows come up with
all their chrome. The other solution is to force all popups to come up
as tabs instead of new windows. I do this too.
But I love your idea of a context menuitem to bring back menus.
Simon Paquet
> I had a situation today in Firefox where an online payment popped up
> in a new window without the usual tool bar or menu bar. I wanted to
> print the payment receipt, but the Print button on the tool bar
> obviously wasn't available. (There was a Print button inside the
> page that used JavaScript to print the page, but it didn't work in
> Firefox.)
>
> The next thing I tried was to right click inside the window to use
> the Print context menu item, but Firefox doesn't give me one. Both
> Thunderbird and Internet Explorer have it, and to me it seems like
> a logical place for it to be. I had to search Bugzilla to find out
> why this wasn't available in Firefox.
>
> There is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=204519)
> with 83 votes requesting this feature, but it's been WONTFIXed.
As the original patch provider in that bug I still find it very sad,
that none of the Firefox developers has at least acknowledged that
various use cases for a print context-menuitem existand that this is
a (minor) usability issue that should be remediated.
Once upon a time, when I was still interested in getting that bug fixed,
Ben at least seemed to care as much, that he would comment in the bug.
Now it seems he only wants this discussion to take place in the
newsgroup, because that will probably not bother him as much as a
personal e-mail. Same goes for the usability lead, Mike Beltzner, to
whom I sent a mail regarding this issue at least a year ago, when he
was still fresh in the project. A mail I never got an answer to.
In my opinion Gerv's proposal is just a hacky workaround and not a real
solution. The whole debate has become a matter of principle instead of
sensible discussion about the pros and cons of adding this context-menu
option.
--
Simon Paquet
Sunbird/Lightning website maintainer
Project website: http://www.mozilla.org/projects/calendar
Developer blog: http://weblogs.mozillazine.org/calendar
Gervase Markham
> In my opinion Gerv's proposal is just a hacky workaround and not a real
> solution.
Which proposal? I don't see one in your message or what I have of this
thread, and there isn't one in the bug.
If you mean having a "show menu bar" context menu item, that is not a
"hacky workaround", it's a solution to the fact that all the menu items
are missing, and we don't want to add a context menu item for each one.
> The whole debate has become a matter of principle instead of
> sensible discussion about the pros and cons of adding this context-menu
> option.
One can't consider context menu additions in isolation; that's what
leads to the 29-item context menus we had (have?) in Seamonkey.
Gerv
Simon Paquet
>> In my opinion Gerv's proposal is just a hacky workaround and not a
>> real solution.
>
> Which proposal? I don't see one in your message or what I have of this
> thread, and there isn't one in the bug.
>
> If you mean having a "show menu bar" context menu item, that is not a
> "hacky workaround", it's a solution to the fact that all the menu items
> are missing, and we don't want to add a context menu item for each one.
Well, I consider it a "hacky workaround" and I'll tell you why. It works
around the addition of the only action you can do on a page, which is
not available in the contextmenu or which cannot be done in another open
window like for example opening the history, the download manager, the
reporter tool or your bookmarks.
So you can easily open a window without any toolbar or menubar and you
can still easily add this page as a bookmark, send the link to a friend,
copy text, save the page, go backward or forward. The only thing you
can't do is printing.
And the only reason I've heard for this usability mistake I've heard in
the last few weeks is "We don't want to clutter the contextmenu". A very
bad excuse.
>> The whole debate has become a matter of principle instead of
>> sensible discussion about the pros and cons of adding this
>> context-menu option.
>
> One can't consider context menu additions in isolation; that's what
> leads to the 29-item context menus we had (have?) in Seamonkey.
No. What lead to that mess in the Suite was an unowned UI, which
everyone could mess around with and which tried to cater to a lot
of different needs.
Firefox in comparison has a strongly-owned UI, so that scenario can be
and has been avoided. Personally I know the CTRL-P shortcut and I could
live without a print-contextmenu-item as long as there was single
reason, why it is not needed besides the bad "We don't want to clutter
the contextmenu" one.
Gervase Markham
> Well, I consider it a "hacky workaround" and I'll tell you why. It works
> around the addition of the only action you can do on a page, which is
> not available in the contextmenu or which cannot be done in another open
> window like for example opening the history, the download manager, the
> reporter tool or your bookmarks.
Oh, I see what you are saying. Hmm.
Here are some other things which aren't on the context menu which are
page-specific:
Find In This Page
Find Again
The ability to turn on/off other toolbars
Text Size
Page Style
Character Encoding
Any other menu item that an extension might add; in my case "Check Page
Links".
Gerv
Simon Paquet
>> Well, I consider it a "hacky workaround" and I'll tell you why. It
>> works around the addition of the only action you can do on a page,
>> which is not available in the contextmenu or which cannot be done
>> in another open window like for example opening the history, the
>> download manager, the reporter tool or your bookmarks.
>
> Oh, I see what you are saying. Hmm.
>
> Here are some other things which aren't on the context menu which
> are page-specific:
Ok, so I missed some things. No problem. Then it comes down to
importance.
> Find In This Page
Pretty important.
> Find Again
Not important, since this option is available via mouse after you
opened the find toolbar.
> The ability to turn on/off other toolbars
If the website decides, that toolbars are not wanted on a page, then
this is pretty contraproductive. It might be a workaround to enable
a "enable toolbars"-option on windows without toolbars and without a
menubar, but this would still be no real solution.
> Text Size
This is a global setting. The text size on a page is not a setting
which you change often. Therefore its exclusion from the contextmenu
is valid.
> Page Style
Expert setting, nothing for the overall contextmenu.
> Character Encoding
See "Text Size"
> Any other menu item that an extension might add; in my case "Check
> Page Links".
Any extension can add or remove items from the contextmenu.
Gervase Markham
>> The ability to turn on/off other toolbars
>
> If the website decides, that toolbars are not wanted on a page, then
> this is pretty contraproductive.
Why so? You may disagree with the website.
>> Text Size
>
> This is a global setting. The text size on a page is not a setting
> which you change often. Therefore its exclusion from the contextmenu
> is valid.
It's not a global setting, it's a per-page setting. And people with poor
eyesight may well use it a lot.
>> Character Encoding
>
> See "Text Size"
It's rather US-centric to say that this is rarely used. What law says
that popup windows can't have bad character encodings set?
>> Any other menu item that an extension might add; in my case "Check
>> Page Links".
>
> Any extension can add or remove items from the contextmenu.
Would you like them all to add one, then?
Gerv
Simon Paquet
>> If the website decides, that toolbars are not wanted on a page, then
>> this is pretty contraproductive.
>
>Why so? You may disagree with the website.
I may disagree with a lot of things. But messing around with developed
content that is not your own is not something that should be done
deliberately with the exception of security or major usability
considerations.
>>> Text Size
>>
>> This is a global setting. The text size on a page is not a setting
>> which you change often. Therefore its exclusion from the contextmenu
>> is valid.
>
>It's not a global setting, it's a per-page setting. And people with poor
>eyesight may well use it a lot.
I don't know which browser you are using, but on my Firefox 2 it's a
global setting (per session). Once I change the text size, it is also
adjusted on other pages I visit later.
>>> Character Encoding
>>
>> See "Text Size"
>
>It's rather US-centric to say that this is rarely used. What law says
>that popup windows can't have bad character encodings set?
Like I said, same as text size: Change it once and there you go.
>>> Any other menu item that an extension might add; in my case "Check
>>> Page Links".
>>
>> Any extension can add or remove items from the contextmenu.
>
>Would you like them all to add one, then?
No. But of course that is completely beside the point of this whole
discussion, which you are trying to steer away from the real issue, which
you haven't adressed in a single post.
There are valid use cases for the inclusion of a print option on the
context menu, which have been completely ignored so far and every time
someone brings them up, another strawman discussion like your
|"One can't consider context menu additions in isolation; that's what
|leads to the 29-item context menus we had (have?) in Seamonkey."
is brought up again.
Simon
--
Sunbird/Lightning Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar
Gervase Markham
> I may disagree with a lot of things. But messing around with developed
> content that is not your own is not something that should be done
> deliberately with the exception of security or major usability
> considerations.
Rubbish. We allow it in lots of places. "Use own fonts and colours".
"Set Text Size". The entire point of Greasemonkey is to mess around with
developed content that is not your own.
Anyway, not being able to Print, Find or read what you are looking at
are major usability concerns.
> I don't know which browser you are using, but on my Firefox 2 it's a
> global setting (per session). Once I change the text size, it is also
> adjusted on other pages I visit later.
...in the same window. And if you can't adjust it in that window in the
first place...
>>>> Character Encoding
>>> See "Text Size"
>> It's rather US-centric to say that this is rarely used. What law says
>> that popup windows can't have bad character encodings set?
>
> Like I said, same as text size: Change it once and there you go.
You don't understand what that menu item does, do you?
Individual web pages may be served in any one of dozens of character
sets. Firefox needs to know the character set to know how to understand
the bytes it is receiving. Pages may have their character set
mislabelled or missing. If so, Firefox attempts to guess. It may guess
wrong on some pages for a site and right on others (depending on the
exact characters which make up the content). If it guesses wrong, you
need to tell it manually for that page.
This setting does not persist from page to page, or window to window.
>>>> Any other menu item that an extension might add; in my case "Check
>>>> Page Links".
>>> Any extension can add or remove items from the contextmenu.
>> Would you like them all to add one, then?
>
> No. But of course that is completely beside the point of this whole
> discussion, which you are trying to steer away from the real issue, which
> you haven't adressed in a single post.
It's not.
Lots of extensions which perform operations in the page add a menu item
to the menu bar. You are saying that we shouldn't make it possible to
view the menu bar in popup windows. Therefore, you are saying that all
these extensions should also add a context menu item in case they need
to be used on such pages.
> There are valid use cases for the inclusion of a print option on the
> context menu,
Are they stronger than the use case for a Find option?
We can add one menu item which makes all the existing features, plus any
added by extensions, available in that window in a way which is easily
understandable to the user, and doesn't lead to unmanageable context
menus. It seems like a no-brainer to me.
> |"One can't consider context menu additions in isolation; that's what
> |leads to the 29-item context menus we had (have?) in Seamonkey."
>
> is brought up again.
Er, that's because it's a reasonable point. All of the things I listed
have the potential to be required on any page. Therefore, if we
considered them all in isolation, we'd add context menu items for all of
them.
Gerv
Simon Paquet
>> I may disagree with a lot of things. But messing around with developed
>> content that is not your own is not something that should be done
>> deliberately with the exception of security or major usability
>> considerations.
>
>Rubbish. We allow it in lots of places. "Use own fonts and colours".
>"Set Text Size".
What in "major usability concerns" did you not understand?
>The entire point of Greasemonkey is to mess around with
>developed content that is not your own.
Greasemonkey is an extension. And there are valid reasons why it is not
included by default.
>Anyway, not being able to Print, Find or read what you are looking at
>are major usability concerns.
Great.
>> I don't know which browser you are using, but on my Firefox 2 it's a
>> global setting (per session). Once I change the text size, it is also
>> adjusted on other pages I visit later.
>
>...in the same window.
Since we have a tabbed interface, I consider this to be enough.
>> No. But of course that is completely beside the point of this whole
>> discussion, which you are trying to steer away from the real issue, which
>> you haven't adressed in a single post.
>
>It's not.
>
>Lots of extensions which perform operations in the page add a menu item
>to the menu bar. You are saying that we shouldn't make it possible to
>view the menu bar in popup windows.
No. I'm saying that it is a hacky workaround. It is a definitely a better
solution than the current situation, but it could obviously be improved.
>Therefore, you are saying that all these extensions should also add a
>context menu item in case they need to be used on such pages.
You have serious reading problems, Gerv. When I learned English "No" was
a negation. Has this changed?
>> There are valid use cases for the inclusion of a print option on the
>> context menu,
>
>Are they stronger than the use case for a Find option?
Yes. "Read" the bug with all the examples.
>> |"One can't consider context menu additions in isolation; that's what
>> |leads to the 29-item context menus we had (have?) in Seamonkey."
>>
>> is brought up again.
>
>Er, that's because it's a reasonable point.
No, it's complete bullshit. And I explained to you why the linkage to the
Seamonkey situation is wrong a few posts earlier. If you would actually
read my postings, you would know that.
>All of the things I listed have the potential to be required on any page.
>Therefore, if we considered them all in isolation, we'd add context menu
>items for all of them.
Usability design means making tradeoffs by identifying the elements which
are *really* important to the user and to weed out all the stuff which is
only mildly interesting or even distracting to the user.
That's what this discussion should be about: Discussing the potential
benefits and drawbacks of a print contextmenu-item and not holding the
26th strawman discussion about the Seamonkey contextmenu disaster.
Asa Dotzler
> Usability design means making tradeoffs by identifying the elements which
> are *really* important to the user and to weed out all the stuff which is
> only mildly interesting or even distracting to the user.
I've read the bug and probably all of the forum posts, the few blog
posts, and the newsgroup threads. I've yet to see any compelling data
that says this is a *really* important issue for any significant number
of users. My reading suggests that this issue falls much closer to the
"mildly interesting" category.
- A
Gervase Markham
> And on the seventh day Gervase Markham spoke:
>> "Set Text Size".
>
> What in "major usability concerns" did you not understand?
For some users, "Use own fonts and colours" and "Set Text Size" are
major usability concerns. You need to hang out with the accessibility
folks a little bit.
>> The entire point of Greasemonkey is to mess around with
>> developed content that is not your own.
>
> Greasemonkey is an extension. And there are valid reasons why it is not
> included by default.
If there were a way we could do it without the implicit security
problems with untrusted code, believe me, it would be in there like a
shot. Opera includes their version by default.
> You have serious reading problems, Gerv. When I learned English "No" was
> a negation. Has this changed?
Then how am I supposed to access these extensions on pages where I can't
get at the menu bar?
> No, it's complete bullshit. And I explained to you why the linkage to the
> Seamonkey situation is wrong a few posts earlier. If you would actually
> read my postings, you would know that.
Clearly I'm not reading your postings. That's how I'm not responding to
them, point by point.
Just because someone disagrees with you doesn't mean he is either stupid
or ignoring you.
> That's what this discussion should be about: Discussing the potential
> benefits and drawbacks of a print contextmenu-item and not holding the
> 26th strawman discussion about the Seamonkey contextmenu disaster.
No, the discussion should be about the general issue. Popup windows
without a menu bar remove function a user might want. How do we fix
that, bearing in mind that we can't know exactly what the function is
because of extensions?
Note that a solution to this problem may not involve the context menu at
all. It might involve making the menu bar compulsory; it might involve
adding a "Show Menu Bar" button to the top right corner.
Gerv
Michael Lefevre
[snip]
>
> Clearly I'm not reading your postings. That's how I'm not responding to
> them, point by point.
Evidently you are reading them. But you're mostly avoiding addressing the
points he was trying to make, and discussing other points of your own.
> No, the discussion should be about the general issue.
That could be one discussion. I happen to agree that this discussion
should be about the point that was originally made (and is still the
subject line). If you have a discussion about the general issue, it
pretty much guarantees that nothing will happen. However, in this case, it
seems pretty unlikely that anything is going to happen on the specific
issue, as it's been discussed to death already and the easier solutions
have been rejected...
> Popup windows without a menu bar remove function a user might want. How
> do we fix that, bearing in mind that we can't know exactly what the
> function is because of extensions?
Why not leave it to the extensions to solve the problem where it's
necessary to do so? The majority of Firefox users don't use extensions
anyway. Printing is something that many users do, and the (apparent)
inability to print the content of popup windows is something that does
come up repeatedly. I haven't seen anyone starting discussions about the
problem of not having access to some extension functions in popup windows
(but maybe I missed it).
--
Michael
Gervase Markham
> Why not leave it to the extensions to solve the problem where it's
> necessary to do so?
Because that leads to each extension adding an item to the context menu.
And context menu bloat is something we want to avoid.
> The majority of Firefox users don't use extensions
> anyway.
So clearly we don't need to take them into account when doing UI design.
> Printing is something that many users do, and the (apparent)
> inability to print the content of popup windows is something that does
> come up repeatedly.
Where did I say that I don't think this is a problem, or that I don't
think it should be fixed? We disagree on how to fix it, not whether it
should be fixed.
Gerv
Michael Lefevre
> Michael Lefevre wrote:
[snip]
>> The majority of Firefox users don't use extensions
>> anyway.
>
> So clearly we don't need to take them into account when doing UI design.
Indeed. If we were going to take them into account, then we might also
need to take them into account when looking at memory usage and security
issues, which would be a big drain on development resources which could
otherwise be better used on the browser as most people use it - without
extensions.
> Where did I say that I don't think this is a problem, or that I don't
> think it should be fixed?
You didn't. Where did I say that you did say that, or that you thought
that?
> We disagree on how to fix it, not whether it should be fixed.
But unless there is agreement about how it should be fixed, then it is
rather unlikely to be fixed. Given that discussions have been going on
around the wider topic of getting access to menus etc in pop-up windows
for at least 5 years (originally in relation to the Suite rather than
Firefox, of course), it doesn't seem likely that agreement is going to be
reached any time soon.
Anyway, I realise at this point I'm not achieving anything but continuing
a thread of pointless bickering, so I'll stop... :-)
--
Michael
Gervase Markham
> On 2006-11-13, Gervase Markham <ge...@mozilla.org> wrote:
>> Michael Lefevre wrote:
> [snip]
>>> The majority of Firefox users don't use extensions
>>> anyway.
>> So clearly we don't need to take them into account when doing UI design.
>
> Indeed.
That was sarcasm; sorry you missed it.
Extensions are a big part of what makes Firefox the flexible platform it
is; of course we should take their existence into account when doing UI
design.
Gerv
Michael Lefevre
> Michael Lefevre wrote:
>> On 2006-11-13, Gervase Markham <ge...@mozilla.org> wrote:
>>> Michael Lefevre wrote:
>> [snip]
>>>> The majority of Firefox users don't use extensions
>>>> anyway.
>>> So clearly we don't need to take them into account when doing UI design.
>>
>> Indeed.
>
> That was sarcasm; sorry you missed it.
As I thought the rest of the paragraph which you snipped made obvious, my
response to your sarcasm was also sarcasm. Sorry you missed that.
> Extensions are a big part of what makes Firefox the flexible platform it
> is; of course we should take their existence into account when doing UI
> design.
Of course. I also think that we should pay more attention to them in
respect of other things, but the Mozilla Corp folks don't seem to agree.
If you can get the Mozilla Corp folks to drive a solution to the wider
issue forward, that would be excellent. However, after several years of
that failing happening, it doesn't seem likely.
But then maybe pushing to address the single, simple issue also isn't
going to happen in any case - certainly nobody seemed to be in a hurry to
respond to the earlier parts of the thread...
--
Michael