394578 - restore "copy folder location" feature to SM, Fix regression caused by patch for bug 369393

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

Bug 369393 sought to remove a feature from Thunderbird only.
As Wada noted in that bug and in bug 180546, SM did not plan to remove
that feature, the "copy folder location" item in the folder context menu.

But the patch for bug 369393 removed the feature from code that is 
common to TB and SM, thereby removing the feature from SM also. 
This is a signficant feature loss to some of us SM users.

Apparently the TB people are unconcerned about their effect on SM.
So, if SM is to retain the feature, SM will have to do work to restore 
that feature in SM code.  Frankly, I think this is a governance issue.

Please do restore the feature.

Comment 1

[[e-mail]]

Should our module owner want to restore the folder location to the context menu thus providing two places in the UI, he can simply back out the removal of the copy folder location menuitem part of attachment 274367 [details] [diff] [review] to bug 369393 sr=me.

Comment 2

[Karsten Düsterloh]

The actual plan was that Magnus fixes this in bug 180546 by showing the file location along with user-friendly display on the first page (General Information) of the folder properties for all folders (instead of just for IMAP as it is now). 
This means either ifdeffing or forking this dialog.

Actually, I think we should fork that dialog, see bug 

The "copy folder location" item as such is a waste of precious UI space. Although I, too, use it frequently, IMO it's not a function important enough to have its own context menu item. It would be accessible from the first page of the folder properties if this is fixed.

I do not pigheadedly insist on removing the context menu item, I think it's useful UI clean-up.

(In reply to comment #0)
> This is a signficant feature loss to some of us SM users.

Could you please describe your usecase?
Why do you think that this function is important enough to warrant its own context menu item?

> Apparently the TB people are unconcerned about their effect on SM.

As true as that may be ...

> Frankly, I think this is a governance issue.

... this is not really the case here.
Unfortunately, Magnus just took bug 180546 after I talked with him, but nothing happened so far.

Comment 3

[Magnus Melin [:mkmelin]]

Yes, I've been offline for a few weeks. Still not sure how to approach this, maybe  putting Location under Name in the properties dialog (for both apps) is the best/simplest thing after all...

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Just to be clear, the old "copy folder location" context menu choice
copied a string to the clipboard that read like this:

news://news.mozilla.org:119/mozilla.dev.tech.crypto

That is a LOT more than merely "mozilla.dev.tech.crypto" which is 
the ONLY thing that is now available in SM's folder properties dialog.

The assertion that SM's context dialog now contains the equivalent 
of the old "copy folder location" is *FALSE*.  The assertion that 
putting the "copy folder location" item back in the context menu would 
duplicate functionality now in SM's folder properties dialog is *FALSE*.

Comment 5

[Karsten Düsterloh]

> The assertion that SM's context dialog now contains the equivalent 
> of the old "copy folder location" is *FALSE*.  The assertion that 
> putting the "copy folder location" item back in the context menu would 
> duplicate functionality now in SM's folder properties dialog is *FALSE*.

I didn't assert that.
I'm well aware that we have a loss of information currently.

Nelson, could you please elaborate: 
- Your actual usecase? Why do you need to copy the path often? (I used that menu item frequently in developing, but that's not the usual usecase, of course.)
- Why do you think that this function is important enough to warrant its own
_context_ menu item?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

The folder context item is valuable real estate PRECISELY because it is 
useful for something for which no other menu is: doing things in the context
of the folder - doing operations that implicitly act on the folder.  
The folder context menu should be used for the operations where it is the 
logical correct fit, where it is the most efficient way of performing 
the said operation.

That is clearly the case for getting the folder URL.  Frankly, it is also 
true for several things now in the tools menu, such as 
- run filters on folder
- run junk mail control on folder
- delete junk in folder

All those operations would be much more efficient if done in the folder context
menu, and the menu item labels would be shorter too, because "on folder" would be completely unnecessary.  But those are outside of the scope of this bug.
This bug is about functionality and efficiency that has been removed from the folder context menu.

The new scheme of bug 180546, with URL in the folder properties menu, is 
WAY less usable than the context menu item.  
It's way more clicks and keystrokes.  
The old way was:
 - right click on folder name
 - click on "copy folder location".  Done!

The new way is:
 - right click on folder name
 - click Properties (wait for new dialog)
 - highlight folder URL
 - type ctrl-C (copy data to clipboard)
 - close dialog 
That's a lot more needless clicking and dragging.

Why do I think this warrants its own context menu?
Let me put the question on you!
 
Why do you think that this functionality should be taken away and made less
efficient, after having been present for years and years without causing 
any trouble?
Why must people defend the preservation of good efficient UI to you?

Comment 7

[Mike Cowperthwaite]

The problem with your argument, Nelson -- as is true in most of the other bugs where you get on your soapbox -- is that you are unwilling to concede that your usage is minority usage.  In this particular case, that menu item is used by only a small percentage -- I would bet less than 5%, and no, I'm not going to do a study to prove the point.  And while a context menu would ideally be all things to all people, in practice it is bad UI to fill a menu with items that are of limited use.

The feature you like would be quite simple to create as an extension, which would work exactly like it did before; and in my opinion, it is incumbent upon you to create it.

Comment 8

[Mark Banner (:standard8)]

(In reply to comment #6)
> The folder context item is valuable real estate PRECISELY because it is 
> useful for something for which no other menu is: doing things in the context
> of the folder - doing operations that implicitly act on the folder.  
> The folder context menu should be used for the operations where it is the 
> logical correct fit, where it is the most efficient way of performing 
> the said operation.

In general I agree with you here.

> That is clearly the case for getting the folder URL.

Possibly. I personally have *never* used the copy folder location function.

What Karsten is asking for is the use case - what do you use copy folder location for?

The other examples that you have given are all things that I would see being used frequently by users and perhaps should have their own items on the context menu.

> Why must people defend the preservation of good efficient UI to you?

When we can't see a useful use case for an item, then why shouldn't we remove it (or move it to a less accessible place)?

It may be "efficient UI" for you, but its not good UI for me. I never use it, why should I have a longer context menu with options I never use and am unlikely to use?

So what do you use it *for*?

Give us an example or two, and you never know we might say "Oh, we never thought of that, yes it should stay on the context menu".

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

So, Mike, you want to take away features that you don't personally use,
and force users to write extensions to restore functionality that has been
in the product since the beginning.  You're going to succeed in driving
me away from SeaMonkey, and others also, by taking away the functionality
that keeps me using these products.  I've contributed over 90 thousand 
lines of code to mozilla.  How many have you?  Why should you drive me away? 
How is it in Mozilla's interest for you to do so? 

Mark, I frequently point people to mozilla newsgroups to discuss issues
that they were discussing in bugs, or in wikis, or in other non-mozilla
newsgroups.  I use the URL that points to news.mozilla.org because that 
is the best, most reliable, way for people to get access to those 
newsgroups, especially for SM or TB users, and even for OE users (I think).
The menu item is the way I get the URL to which I point people.

Comment 10

[Ian Neal]

Not blocking 2.0a1 on this, renominating for 2.0 final though.

Comment 11

[Robert Kaiser]

This bug is open but targeted for seamonkey2.0a1, which has been released a long time ago. Please set the target milestone to an appropriate value, "---" if it has no specific target.

Comment 12

[Magnus Melin [:mkmelin]]

I think the use case for the "old behavior" will be covered fairly well with bug 35689.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Robert, This bug is two years old.  Apparently you have no intention of 
fixiing it.  Please be honest and mark it WONTFIX, instead of playing this
school yard game of saying "we won't fix it because it's targeted at 
last year's release".

Comment 14

[Ian Neal]

Nelson, would porting Bug 35689 (once it is fixed), be a suitable solution?

Comment 15

[Robert Kaiser]

This at least doesn't block the release, even though a patch might be taken - I'll leave that or an eventual WONTFIX up to Karsten as the mailnews module owner.