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.
Target Milestone: --- → seamonkey2.0alpha
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.
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.
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...
OS: Windows XP → All
Hardware: PC → All
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*.
> 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?
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?
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.
(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".
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.
Not blocking 2.0a1 on this, renominating for 2.0 final though.
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.
I think the use case for the "old behavior" will be covered fairly well with bug 35689.
QA Contact: message-display
Target Milestone: seamonkey2.0a1 → ---
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".
Nelson, would porting Bug 35689 (once it is fixed), be a suitable solution?
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.
Flags: blocking-seamonkey2.0? → blocking-seamonkey2.0-
You need to log in before you can comment on or make changes to this bug.