Closed Bug 1013904 Opened 6 years ago Closed 6 years ago

Text not selectable in in-content prefs

Categories

(Firefox :: Preferences, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 32

People

(Reporter: jboriss, Assigned: mano)

References

(Blocks 1 open bug)

Details

(Whiteboard: p=13 s=it-32c-31a-30b.3 [qa!])

Attachments

(2 files, 1 obsolete file)

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
Flags: firefox-backlog+
FWIW not all the text isn't selectable in the add-ons manager either.
(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
Whiteboard: p=0 [qa?]
FWIW, setting -moz-user-select: text and -moz-user-focus: normal isn't enough for some reason.
(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
It's bug 203291 that breaks this, I think, but it seems to me a workaround is possible.
Whiteboard: p=0 [qa?] → p=13 s=it-32c-31a-30b.3 [qa+]
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>.
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.
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 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.
Attachment #8430003 - Flags: review?(enndeakin) → review-
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.
Flags: needinfo?(enndeakin)
Attached patch patchSplinter Review
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.
Attachment #8431359 - Flags: review?(jaws)
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?
Attachment #8431359 - Flags: review?(jaws) → review+
Flags: needinfo?(enndeakin)
I filed bug 1018339 for the checkboxes and radio buttons issue.
https://hg.mozilla.org/mozilla-central/rev/67ad7ee35569
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
QA Contact: camelia.badau
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.
Flags: needinfo?(camelia.badau)
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"
Flags: needinfo?(camelia.badau) → needinfo?(mano)
(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.
Flags: needinfo?(mano)
(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.
(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 .
Flags: needinfo?(mano)
(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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(mano)
Logged bug 1021715 .
Whiteboard: p=13 s=it-32c-31a-30b.3 [qa+] → p=13 s=it-32c-31a-30b.3 [qa!]
You need to log in before you can comment on or make changes to this bug.