616437 - Text in details view of add-on should be selectable

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[B.J. Herbison]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101202 Firefox/4.0b8pre
Build Identifier: 4.0b8pre (installed from nightly on 3 December 2010)

When detailed information about an add-on is shown, all the text should be selectable.

I first noticed the issue when entering bug 616434, I wanted to copy text from the table at the bottom to past into the bug report to ensure the text I entered was accurate, but I would also like to be able to be able to copy names and descriptions of extensions (for example, to e-mail to someone who might be interested in an extension).

Reproducible: Always

Steps to Reproduce:
1.Visit Add-ons Manager/Extensions.
2.Click a "More" link.
3.Select some of the displayed text.
Actual Results:  
The text can not be selected.

Expected Results:  
All text could be selected.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As given on bug 601640 we have it only enabled for the release notes at the moment. I thought there was already a bug for this request, but I can't find it right now. Blair, can you remember?

Comment 2

[u279076]

In addition to this, links within the details page should be clickable.  For example, the Nightly Tester Tools details contain a link to wiki.mo which is not clickable.

Either way, marking this as NEW and adding DUPEME to the whiteboard.  Blair, if it's on file already, please dupe it.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #1)
> As given on bug 601640 we have it only enabled for the release notes at the
> moment. 

Correct.

> I thought there was already a bug for this request, but I can't find it
> right now. Blair, can you remember?

Hmm, I was sure we did too, but can't find it. Either way, pretty sure it was a WONTFIX - this is application UI (even if its in a tab), and in general, text in application UI isn't selectable.

(In reply to comment #2)
> In addition to this, links within the details page should be clickable.  For
> example, the Nightly Tester Tools details contain a link to wiki.mo which is
> not clickable.

This has been brought up a couple of times, but I don't know if we have a bug for it (couldn't find one). Unfortunately, there are some security concerns if we start parsing text like that. But maybe we could look at it again after 4.0?

Comment 4

[B.J. Herbison]

(In reply to comment #3)
> 
> Hmm, I was sure we did too, but can't find it. Either way, pretty sure it was a
> WONTFIX - this is application UI (even if its in a tab), and in general, text
> in application UI isn't selectable.
> 

Is this part of the Firefox style guidelines? Where is it documented? And if, after reading the guidelines I don't like them, what would be the best forum to discuss them in?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I would have to second that being able to copy those texts would be very useful. The text is not part of the Firefox code but comes from add-ons. Even with being a tab now, we should be have in most cases like content. I would assume that most users would rely on that. Lets get feedback from UX.

Comment 6

[Steve Roylance]

Mozilla/5.0 (X11; Linux i686; rv:2.0b11) Gecko/20110210 Firefox/4.0b11

middle clicking (open in new [tab]) does not work for URLs in Add-on manager
also unable to copy URLs from the Add-on manager

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #6)
> middle clicking (open in new [tab]) does not work for URLs in Add-on manager
> also unable to copy URLs from the Add-on manager

We are always open URLs in a new tab with a left-click. For the missing middle click you can file a new bug.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #7)
> We are always open URLs in a new tab with a left-click. For the missing middle
> click you can file a new bug.

For reference this is now bug 637552.

Comment 9

[Jennifer Morrow [:Boriss] (UX)]

Both selecting text and middle clicking (bug 637552, thanks Henrik) are very important behaviors. They're good examples of papercuts - little inconsistencies with subvert the expectations of users. Definitely great to have in 4.0.

(In reply to comment #3)
> (In reply to comment #1)
> Unfortunately, there are some security concerns if
> we start parsing text like that. But maybe we could look at it again after 4.0?

Can you elaborate on the security concerns, Blair?

Comment 12

[Mark Callow]

(In reply to comment #3)
> Hmm, I was sure we did too, but can't find it. Either way, pretty sure it
> was a WONTFIX - this is application UI (even if its in a tab), and in
> general, text in application UI isn't selectable.
> 

And the fact that text in UI is not selectable has been a pain in the **** for years when reporting bugs - particularly when the UI is a message box showing an error message. Fortunately a few sensible applications have started to make such text selectable. Just because something is tradition does not mean it is good or correct.

Another more pithy comment comes to mind as the add-on UI is just another tab. If it walks like a duck and quacks like a duck, it is a duck.

Comment 13

[B.J. Herbison]

(In reply to comment #4)
> (In reply to comment #3)
> > 
> > Hmm, I was sure we did too, but can't find it. Either way, pretty sure it was a
> > WONTFIX - this is application UI (even if its in a tab), and in general, text
> > in application UI isn't selectable.
> > 
> 
> Is this part of the Firefox style guidelines? Where is it documented? And
> if, after reading the guidelines I don't like them, what would be the best
> forum to discuss them in?

Anyone have any idea? Is there any Firefox or Mozilla policy or guideline on what text should be selectable?

If there isn't a guideline, maybe the user experience team chould be asked to to look at the issue instead of using "tradition" as a basis. For me this is a "paper cut" issue -- it is frustrating when the browser has the text and won't share it.

Comment 14

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to comment #13)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > 
> > > Hmm, I was sure we did too, but can't find it. Either way, pretty sure it was a
> > > WONTFIX - this is application UI (even if its in a tab), and in general, text
> > > in application UI isn't selectable.
> > > 
> > 
> > Is this part of the Firefox style guidelines? Where is it documented? And
> > if, after reading the guidelines I don't like them, what would be the best
> > forum to discuss them in?
> 
> Anyone have any idea? Is there any Firefox or Mozilla policy or guideline on
> what text should be selectable?
> 
> If there isn't a guideline, maybe the user experience team chould be asked
> to to look at the issue instead of using "tradition" as a basis. For me this
> is a "paper cut" issue -- it is frustrating when the browser has the text
> and won't share it.

If we just used tradition as a basis then this bug would have been closed as WONTFIX a while ago. UX already made an initial comment in comment 9. The bug is marked as uiwanted to get a final decision on what exactly should/shouldn't be selectable.

Comment 15

[Mark Callow]

Bug 673831, which was marked as a duplicate of this, was about text on the Add-Ons manager page (the page showing a list of all the installed add-ons, etc). This bug is requesting selectable text on an add-on's details page. Close but not an exact duplicate. When the UX team considers this bug, please have a wider view than just the details pages.

Comment 17

[Dan Jacobson]

Let me start out the discussion on a good foot by saying whoever
thinks it is good to keep this broken is a total clod.

Here we are clearly staring at text and links but helpless, unable to
copy them, without a pencil and paper. What are they, copyrighted?

You fellows figure it out. Find a way to make them copyable realsoon!

Comment 18

[Dan Jacobson]

The fun starts when you first arrive in Tools -> Add-ons ! Right there you will find loads of items that you can't copy without a pencil. Be it links or text.

Comment 20

[patrickjdempsey]

I can understand possible security concerns about having active links embedded in the browser chrome.  However that does not have any bearing on whether or not a user should be able to select text and copy text manually.  The only argument against this seems to be that browser chrome doesn't traditionally allow for user select and copy text.  The problem is, there is no way for a user to know that this is browser chrome, and in fact it looks more like a website than part of the browser for several reasons:

- It is located within the content area of the browser like a webpage.
- The Get Add-ons pane actually does load a webpage and does allow for select and copy.
- The text and image for the details descriptions is loaded from a webpage and that page does allow for select and copy.
- The entire Add-ons manager is styled like a webpage and has custom button styles like a webpage instead of OS-integrated styles like the rest of the Firefox UI.
- The details pages *do* contain some things that look active hyperlinks, unlike almost the entire rest of the Firefox browser chrome which uses buttons instead of hyperlinks.

Given all of that, I doubt there are many people outside of the developers circle who know that the details pages are not web content. If the details pages were not meant to act like web content, then why all of the hard work to make them look like it?  But that doesn't tell us why we should have the ability to select and copy text... that comes in understanding what kind of information is commonly posted in the add-on's descriptions, which may include:

- Links to companion/associated add-ons or userStyles.
- Links to off-site development builds.
- Links to online user-guides, tutorials, instructional videos, etc.
- Links to off-site support forums/feedback mechanisms.
- Links to articles related to the reason for the creation of the add-on.
- Sample code snippets.
- Companion userChrome.css/userContent.css modifications.
- The name of software, a company, or developer that a user may desire to research further.

9 out of 10 of the top 10 Most Popular extensions on AMO feature one or more of those items, including two projects built by Mozilla Labs.  It is fairly trivial to add the support for selectable text by adding this line:

#addons-page label,
#addons-page description {
  -moz-user-select: text;
}

This gets us as far as being able to use keyboard shortcuts, but what we need after that is a functional context menu.

Comment 21

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to jidanni from comment #17)
> Let me start out the discussion on a good foot by saying whoever
> thinks it is good to keep this broken is a ******

Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - the language you used isn't acceptable here.

Comment 23

[u279076]

Very old dupe -- see bug 246400

Comment 24

[u279076]

Actually, my mistake -- this was about the old About dialog...reverting the change.

Comment 28

[George R. Goffe]

Aleksej,

This problem is NOT resolved. I'm still having this problem.

George...

Comment 29

[[:Aleksej]]

George, I know, me too.

Comment 30

[[:Aleksej]]

George, I only indicated that your report is the same as this one, and stuff should happen here, because this report is older.

Comment 31

[George R. Goffe]

Aleksej,

Oh. Ok... I thought  you were closing this bug as fixed.

Thanks,

George...

Comment 33

[George R. Goffe]

Hi,

Can someone tell me what the current status of this request is please? To me, the problem seems to be rather trivial to implement... but, I'm not a developer.

I would be MOST interested in being able to copy text from this area. There is often instructions with data that needs to be entered and links that users would like to use. Copying would be most useful.

Thanks,

George...

Comment 34

[Lee_Dailey]

howdy George R. Goffe,

this extension ...
Add-ons Manager Context Menu by LouCypher 
- http://loucypher.github.io/AM_contextmenu/

... adds several items to the addon manager windows context menu. it does NOT allow copying from the details view. however, since it does add several items to copy - such as name, version, URL, etc. - you may be able to talk the author into adding such an ability. perhaps as another specific-to-this-bug extension so that someone would have a starting place for adding the ability to ff/sm/tb as a builtin function.

take care,
lee

Comment 35

[YF (Yang)]

Attachment: bug616437.patch

Comment 36

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/integration/fx-team/rev/3f54c130e895

Comment 37

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3f54c130e895

Comment 38

[patrickjdempsey]

Is there to be a follow-up patch for the context menu? because as I mentioned in Comment 20 that is not fixed by the CSS.

Comment 39

[Elbart]

Oh, that's it?

Neither the "last updated"-date, the homepage or the author-name are selectable, which also applies to the details-view of plugins.
Speaking of plugins: For some reason "mime-types" and "file" are selectable.

Comment 41

[B.J. Herbison]

This but is not fixed. The version number, the last updated date and home page (and the labels for those values) are still not selectable.

Comment 42

[Andrei Vaida [:avaida]]

I was able to confirm the fix for this issue on Firefox 30 Beta 3 (Build ID: 20140508121358), using some of the most popular add-ons with:
  * Windows 7 64-bit [1],
  * Ubuntu 12.04 32-bit [2],
  * Mac OS X 10.8.5  [3].

However, as previously stated in Comment 38 and Comment 41, an actual context menu for text selection actions (e.g. copy) is not available and the text displayed in the "Contribute" section along with the one from "Last Updated" and "Homepage" fields cannot be selected. 

YF (Yang), please confirm whether the above behavior is intended or not.


[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
[2] Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0
[3] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0

Comment 43

[YF (Yang)]

(In reply to Andrei Vaida, QA [:avaida] from comment #42)
> However, as previously stated in Comment 38 and Comment 41, an actual
> context menu for text selection actions (e.g. copy) is not available and the
> text displayed in the "Contribute" section along with the one from "Last
> Updated" and "Homepage" fields cannot be selected. 
> 
> YF (Yang), please confirm whether the above behavior is intended or not.

Intended.

#detail-dateUpdated .detail-row-value seem impossible do by CSS, it use 'value' attribute instead of #text child element. as well as, I don't think this field needs be selectable.
#detail-homepage also is difficult, it is a URL, selectable and clickable seem conflict.
As for the context menu, I don't know how to do this yet, maybe the needs more efforts, but no progress now.

Regret for did not indicate in the patch comment, the patch is a part for the bug.

Comment 44

[Mark Callow]

(In reply to YF (Yang) from comment #43)
> 
> #detail-homepage also is difficult, it is a URL, selectable and clickable
> seem conflict.

On ordinary web-pages the context menu has a "Copy Link Location" entry. It is also possible to select URL text by clicking outside the link and dragging across it. It than then be copied with CTRL-C or with Copy on the main (or whatever it is called) menu at top right in FF29. One or both of these should be possible on Add-Ons page.

Comment 45

[patrickjdempsey]

In extensions.js, the context menu is structured by the following code:

var contextMenu = document.getElementById("addonitem-popup");
    contextMenu.addEventListener("popupshowing", function contextMenu_onPopupshowing() {
      var addon = gViewController.currentViewObj.getSelectedAddon();
      contextMenu.setAttribute("addontype", addon.type);
      
      var menuSep = document.getElementById("addonitem-menuseparator");
      var countEnabledMenuCmds = 0;
      for (let child of contextMenu.children) {
        if (child.nodeName == "menuitem" &&
          gViewController.isCommandEnabled(child.command)) {
            countEnabledMenuCmds++;
        }
      }
      
      // with only one menu item, we hide the menu separator
      menuSep.hidden = (countEnabledMenuCmds <= 1);
      
    }, false);

According to the documentation here: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/context-menu that needs to be amended to include a var for selected text via SelectionContext()

Comment 46

[Andrei Vaida [:avaida]]

(In reply to YF (Yang) from comment #43)
> Intended.
> 
> #detail-dateUpdated .detail-row-value seem impossible do by CSS, it use
> 'value' attribute instead of #text child element. as well as, I don't think
> this field needs be selectable.
> #detail-homepage also is difficult, it is a URL, selectable and clickable
> seem conflict.
> As for the context menu, I don't know how to do this yet, maybe the needs
> more efforts, but no progress now.
> 
> Regret for did not indicate in the patch comment, the patch is a part for
> the bug.

Thank you for clarifying this, YF. Marking this issue verified based on Comment 43.

Comment 47

[Steve Roylance]

Build identifier: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0

problem still exits
the details of the extension is split into 3 panels, 
text in panel 1 is selectable
text in panel 2 is NOT selectable
text and links in panel 3 are NOT selectable

Comment 48

[u279076]

Steve, I believe what you are seeing is expected given the previous comments, I'll leave it to the devs to confirm that and advise you further.

Comment 49

[Mark Callow]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #48)
> Steve, I believe what you are seeing is expected given the previous
> comments, I'll leave it to the devs to confirm that and advise you further.

This kind of comment is not very helpful. It may well be the behavior the devs are currently expecting but it is not the behavior requested since the beginning of this bug. Therefore the bug is not fixed.

The essential issue is that you have made the Add-Ons page and add-ons' details pages look like web pages but they in many ways the UX still differs from what you have on a web page. Why the devs don't use the obvious solution, build real HTML pages from the add-on information I don't know.

Comment 50

[Tony Mechelynck [:tonymec]]

(In reply to Andrei Vaida, QA [:avaida] from comment #46)
> (In reply to YF (Yang) from comment #43)
[…]
> > #detail-homepage also is difficult, it is a URL, selectable and clickable
> > seem conflict.
[…]

In the browser, the trick to select a URL (in order to Copy its text, then Paste it elsewhere) is to start the mouse-drag just a tiny wee bit outside the URL itself. Then dragging tyhe mouse over the URL selects it.

In about:addons, this doesn't work, and the Home Page URL has a context menu which is no different from that of the rest of the page — No "Copy Link Location" in it.