Text in details view of add-on should be selectable

VERIFIED FIXED in mozilla30

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
7 years ago
3 years ago

People

(Reporter: B.J. Herbison, Assigned: YF (Yang))

Tracking

({uiwanted})

Trunk
mozilla30
uiwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [AOMTestday][dupeme])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Whiteboard: [AOMTestday]
Version: 1.9.2 Branch → Trunk
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?
Summary: Add-ons Manager: Text in description of add-on should be selectable → Text in description of add-on should be selectable
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [AOMTestday] → [AOMTestday][dupeme]
(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?
(Reporter)

Comment 4

7 years ago
(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?
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.
Keywords: uiwanted

Comment 6

7 years ago
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
(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.
(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.
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?
Duplicate of this bug: 668683
Summary: Text in description of add-on should be selectable → Text in details view of add-on should be selectable
Duplicate of this bug: 673831

Comment 12

6 years ago
(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.
(Reporter)

Comment 13

6 years ago
(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.
(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

6 years ago
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.
Duplicate of this bug: 677512

Comment 17

6 years ago
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

6 years ago
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.
Duplicate of this bug: 686109

Comment 20

6 years ago
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.
(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.
Duplicate of this bug: 759274
Very old dupe -- see bug 246400
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 246400
Actually, my mistake -- this was about the old About dialog...reverting the change.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Duplicate of this bug: 793633

Updated

4 years ago
Duplicate of this bug: 921832

Updated

4 years ago
Duplicate of this bug: 804367

Comment 28

4 years ago
Aleksej,

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

George...

Comment 29

4 years ago
George, I know, me too.

Comment 30

4 years ago
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

4 years ago
Aleksej,

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

Thanks,

George...
(Assignee)

Updated

4 years ago
Duplicate of this bug: 983224

Comment 33

4 years ago
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

4 years ago
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
(Assignee)

Comment 35

4 years ago
Created attachment 8391834 [details] [diff] [review]
bug616437.patch
Attachment #8391834 - Flags: review?(bmcbride)
Attachment #8391834 - Flags: review?(bmcbride) → review+
https://hg.mozilla.org/integration/fx-team/rev/3f54c130e895
https://hg.mozilla.org/mozilla-central/rev/3f54c130e895
Assignee: nobody → yfdyh000
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30

Comment 38

4 years ago
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.
Keywords: verifyme

Comment 39

4 years ago
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.
Duplicate of this bug: 1008570
(Reporter)

Comment 41

4 years ago
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.
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
Flags: needinfo?(yfdyh000)
Keywords: verifyme
(Assignee)

Comment 43

4 years ago
(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.
Flags: needinfo?(yfdyh000)

Comment 44

4 years ago
(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

4 years ago
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()
(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.
Status: RESOLVED → VERIFIED

Comment 47

3 years ago
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
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

3 years ago
(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.
(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.
You need to log in before you can comment on or make changes to this bug.