1013904 - Text not selectable in in-content prefs

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Jennifer Morrow [:Boriss] (UX)]

This is necessary:

1. To be consistent with the rest of the web
2. To not negatively surprise users who rightly would assume text be selectable
3. To aid users who need to copy for support issues, particularly helping others

Comment 1

[u428464]

FWIW not all the text isn't selectable in the add-ons manager either.

Comment 2

[u428464]

(In reply to Guillaume C. [:ge3k0s] from comment #1)
> FWIW not all the text isn't selectable in the add-ons manager either.

* not all the text is selectable

Comment 3

[Asaf Romano (gone)]

FWIW, setting -moz-user-select: text and -moz-user-focus: normal isn't enough for some reason.

Comment 4

[Elbart]

(In reply to Guillaume C. [:ge3k0s] from comment #1)
> FWIW not all the text isn't selectable in the add-ons manager either.
bug 616437

Comment 5

[Asaf Romano (gone)]

It's bug 203291 that breaks this, I think, but it seems to me a workaround is possible.

Comment 6

[Asaf Romano (gone)]

So the problem is that minimal-xul.css is used rather than the full xul.css, and that version simply declares
* {
  -moz-user-select: none;
}

and due to bug 203291, we'd have to override -moz-user-select in nasty ways.

I need to check with Neil why minimal-xul.css is used here, and if it should be used, why it sets -moz-user-select this way.

Comment 7

[Asaf Romano (gone)]

Consider the last comment non-existent.

Comment 8

[Asaf Romano (gone)]

So, again, ignore my previous comments.

-moz-user-select: text does work if I switch the labels from the form of <label value="MyValue"/> to <label>MyValue</label>.

Comment 9

[Asaf Romano (gone)]

And that actually makes sense given how selection work, so I'm going to move "fix" all the xul label in preferences not to show text using the value attribute.

Comment 10

[Asaf Romano (gone)]

There are few not-so-informative bugs I could find on related issue, namely bug 451254, bug 51967 and bug 546387. It seems that the behavior regressed at some point, but that it was always somewhat buggy. I'll double check with Neil if there's some easy workaround/hack for the broader issue, but so far it seems to me the way to go is to make sure all preferences isn't implemented by anonymous content. For labels and descriptions, this doesn't involves any platform or xbl changes, but <caption> elements, and maybe some other elements I overlooked, would need small changes for handling text nodes content.

I forgot to mention that checkboxes and radiobuttons don't need any work (apart -moz-user-select, that is).

Comment 11

[Asaf Romano (gone)]

Attachment: make it possible to enable selection in caption elements

Comment 12

[Neil Deakin]

Comment on attachment 8430003 [details] [diff] [review]
make it possible to enable selection in caption elements

You have a <children> element nested inside another one which isn't going to quite work.

If you don't need the image, you could actually just use:
  <caption><description>Text</description></caption>
and not change the binding.

Comment 13

[Asaf Romano (gone)]

Neil, the problem is that I won't get .caption-text styling. Of course, I could change the selectors (they're not generic - everything is in preference.css, I think), but I was trying to avoid that.

I see you point about children now, but surprisingly it did work. Odd.

Comment 14

[Asaf Romano (gone)]

Attachment: patch

Annoying, isn't it?

I took Neil's advice about captions.

One thing that's still semi-broken is radio buttons and checkboxes. They're affected by bug 451254: their text is selectable, but only on its own.

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8431359 [details] [diff] [review]
patch

Review of attachment 8431359 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, this will have the added benefit of the labels wrapping if necessary.

::: browser/components/preferences/in-content/advanced.xul
@@ +299,5 @@
>                    label="&overrideSmartCacheSize.label;"
>                    accesskey="&overrideSmartCacheSize.accesskey;"/>
>          <hbox align="center" class="indent">
>            <label id="useCacheBefore" control="cacheSize"
> +                accesskey="&limitCacheSizeBefore.accesskey;">

nit: i had to rebase this patch locally to test it. if you have to rebase this change here, can you line up this attribute with the 'id' attribute above it?

Comment 16

[Asaf Romano (gone)]

https://hg.mozilla.org/integration/fx-team/rev/67ad7ee35569

Comment 17

[Asaf Romano (gone)]

I filed bug 1018339 for the checkboxes and radio buttons issue.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/67ad7ee35569

Comment 19

[Marco Mucci [:MarcoM]]

Hi Camelia, will it be possible to have this bug verified by end of day this Friday?  Our current Iteration ends on Monday June 9.

Comment 20

[Camelia Badau [:cbadau], Desktop QA]

Verified on Windows 7 64bit, Mac OSX 10.8.5 and Ubuntu 13.10 32bit using latest Nightly 32.0a1 (buildID: 20140602072051) and the following issues were found: 
- if you want to select the entire content of a Tab (e.g General tab), when drag-selecting from top to bottom the selection is not correctly and fully performed - it may be caused by the issue of the checkboxes and radio buttons (bug 1018339)
- sometimes, the selected text can no longer be deselected when clicking elsewhere in the page (only if you click on the row containing the selected text, the deselection is performed)
- if you select the name (text) of a Tab from the left side of page, this Tab will be opened even if you want maybe only to copy the name of this tab, not to move on it (e.g: I'm on General Tab; I select the text "Security" from the left side of page -> The Security tab is displayed, instead of General Tab which I was previously) - is this the intended behaviour?
- under Advanced Tab -> the name(text) of the categories (General, Data choices, Network, Update, Certificates) is not selectable
- only on Mac: ctrl+A -> the name (text) of tabs from the left side of page is almost invisible (because of selection) - see screenshot "ISSUE.PNG"

Comment 21

[Camelia Badau [:cbadau], Desktop QA]

Attachment: ISSUE.png

Comment 22

[Asaf Romano (gone)]

(In reply to Camelia Badau, QA [:cbadau] from comment #20)
> Verified on Windows 7 64bit, Mac OSX 10.8.5 and Ubuntu 13.10 32bit using
> latest Nightly 32.0a1 (buildID: 20140602072051) and the following issues
> were found: 
> - if you want to select the entire content of a Tab (e.g General tab), when
> drag-selecting from top to bottom the selection is not correctly and fully
> performed - it may be caused by the issue of the checkboxes and radio
> buttons (bug 1018339)

Yes, that's it.

> - sometimes, the selected text can no longer be deselected when clicking
> elsewhere in the page (only if you click on the row containing the selected
> text, the deselection is performed)

I expect that to happen for checkboxes/radiobuttons due to the same bug. In short, the issue in that bug makes radio buttons have their own selection "zone".

Does it also happen for labels?

> - if you select the name (text) of a Tab from the left side of page, this
> Tab will be opened even if you want maybe only to copy the name of this tab,
> not to move on it (e.g: I'm on General Tab; I select the text "Security"
> from the left side of page -> The Security tab is displayed, instead of
> General Tab which I was previously) - is this the intended behaviour?

I don't know. We've similar issues with links in the content area. Please file a bug and needinfo? ux.

> - under Advanced Tab -> the name(text) of the categories (General, Data
> choices, Network, Update, Certificates) is not selectable

Known. I'm not sure we want tabs title to be selectable. It's much harder to fix though. I'll file a bug.

> - only on Mac: ctrl+A -> the name (text) of tabs from the left side of page
> is almost invisible (because of selection) - see screenshot "ISSUE.PNG"

File a bug please. The color has to change.

Comment 23

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Mano (needinfo? for any questions; not reading general bugmail) from comment #22)
> (In reply to Camelia Badau, QA [:cbadau] from comment #20)
> > - if you select the name (text) of a Tab from the left side of page, this
> > Tab will be opened even if you want maybe only to copy the name of this tab,
> > not to move on it (e.g: I'm on General Tab; I select the text "Security"
> > from the left side of page -> The Security tab is displayed, instead of
> > General Tab which I was previously) - is this the intended behaviour?
> 
> I don't know. We've similar issues with links in the content area. Please
> file a bug and needinfo? ux.

This is happening because we switch tabs on mousedown instead of click or mouseup. We should continue to select browser tabs on mousedown (the taps at the top of the browser window), but we can probably change these category tabs and the tabs in the Advanced pane to only get selected on click.

Comment 24

[Camelia Badau [:cbadau], Desktop QA]

(In reply to Mano (needinfo? for any questions; not reading general bugmail) from comment #22)

> > - sometimes, the selected text can no longer be deselected when clicking
> > elsewhere in the page (only if you click on the row containing the selected
> > text, the deselection is performed)
> 
> I expect that to happen for checkboxes/radiobuttons due to the same bug. In
> short, the issue in that bug makes radio buttons have their own selection
> "zone".
> 
> Does it also happen for labels?
> 

Yes, it also happen for labels. Should I file a separately bug for this problem? 

> > - if you select the name (text) of a Tab from the left side of page, this
> > Tab will be opened even if you want maybe only to copy the name of this tab,
> > not to move on it (e.g: I'm on General Tab; I select the text "Security"
> > from the left side of page -> The Security tab is displayed, instead of
> > General Tab which I was previously) - is this the intended behaviour?
> 
> I don't know. We've similar issues with links in the content area. Please
> file a bug and needinfo? ux.
> 

I logged bug 1020295 and CC'ed you. 

> 
> > - only on Mac: ctrl+A -> the name (text) of tabs from the left side of page
> > is almost invisible (because of selection) - see screenshot "ISSUE.PNG"
> 
> File a bug please. The color has to change.

I logged bug 1020285 .

Comment 25

[Asaf Romano (gone)]

(In reply to Camelia Badau, QA [:cbadau] from comment #24)
> (In reply to Mano (needinfo? for any questions; not reading general bugmail)
> from comment #22)
> 
> > > - sometimes, the selected text can no longer be deselected when clicking
> > > elsewhere in the page (only if you click on the row containing the selected
> > > text, the deselection is performed)
> > 
> > I expect that to happen for checkboxes/radiobuttons due to the same bug. In
> > short, the issue in that bug makes radio buttons have their own selection
> > "zone".
> > 
> > Does it also happen for labels?
> > 
> 
> Yes, it also happen for labels. Should I file a separately bug for this
> problem? 
> 

Yes, please.

I'll look into the follow ups, but as for this bug, I think we're done.

Comment 26

[Camelia Badau [:cbadau], Desktop QA]

Logged bug 1021715 .