1292900 - Firefox touch carets don't look the same as the native Windows touch carets

Status: NEW

(Toolkit :: General, defect)

Description

[Jim Mathies [:jimm]]

The current touch carets are little blue teardrops, native selection carets are round O's.

Comment 1

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

[Tracking Requested - why for this release]: This is part of the touch-friendly carets that are planned to release in Firefox 50. We should make sure that these match the native look and feel of the platform as the current teardrop design looks out of place on Windows 10.

Comment 2

[Justin Dolske [:Dolske]]

Because I was curious... Looks like these images originally landed for B2G use (see bug 987718 / bug 1054889 / bug 1096185).

See https://dxr.mozilla.org/mozilla-central/source/editor/composer/res/, text_caret*.png

These end up as resource://gre-resources/[e-mail] and such (see ua.css).

Not sure what the best way to fix this is... Seems like these should ultimately end up as assets in /[browser|toolkit]/themes. But I suspect platform wouldn't want Gecko to have a dependency on Toolkit? Although maybe there's some flexibility since it's pref controlled? Have it disabled in all.js, and enable it in firefox.js?

Can the theme jar.mn use the |override| directive for resource://?

Alternatively it would be nice to pull these from the native OS via -moz-appearance, but I assume that's a lot more work.

Comment 3

[Marcia Knous [:marcia]]

Tracking 51+ based on Comment 1.

Comment 4

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

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> [Tracking Requested - why for this release]: This is part of the
> touch-friendly carets that are planned to release in Firefox 50. We should
> make sure that these match the native look and feel of the platform as the
> current teardrop design looks out of place on Windows 10.

In this comment I meant to say "Firefox 51". The tracking flags are correct.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Justin Dolske [:Dolske] from comment #2)
> Alternatively it would be nice to pull these from the native OS via
> -moz-appearance, but I assume that's a lot more work.

We don't a way of getting these through the system under win32 as far as I'm aware. They are pretty easy to create though, shorlander put standard def versions of these together for metrofx, I'll try to track those down.

Comment 6

[Jim Mathies [:jimm]]

Attachment: selection-monocle.zip

we had three resolutions too.

Comment 7

[:Gijs (he/him)]

Any CSS/images we add here should probably live in toolkit.

Comment 8

[Gerry Chang [:gchang]]

Hi :jimm,
Will you help to find someone on this issue?

Comment 9

[Jim Mathies [:jimm]]

(In reply to Gerry Chang [:gchang] from comment #8)
> Hi :jimm,
> Will you help to find someone on this issue?

I'm not sure who would work on this, someone from the front end team maybe? Who's heading up our touch support work?

Comment 10

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #9)
> (In reply to Gerry Chang [:gchang] from comment #8)
> > Hi :jimm,
> > Will you help to find someone on this issue?
> 
> I'm not sure who would work on this, someone from the front end team maybe?
> Who's heading up our touch support work?

I think it's either :kats, or they might know who it is. :-)

Comment 11

[Kartikaya Gupta (email:[e-mail])]

I'm doing the touch support stuff on the platform side, I'm not aware of anybody taking the front-end bits really. This sounds straightforward enough that I can probably do it assuming somebody can make the relevant images for us to use.

Comment 12

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

Stephen, do you know who may have these images?

Comment 13

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

Sorry, I didn't realize these were posted when the bug was filed. Though the ones that Edge use have a blue border but the attachments here have a black border.

Comment 14

[Stephen Horlander [:shorlander]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #13)
> Sorry, I didn't realize these were posted when the bug was filed. Though the
> ones that Edge use have a blue border but the attachments here have a black
> border.

These were made for Windows 8 / Metro. Things may have changed since then?

Comment 15

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

Yeah, that's what it looks like. Though using black here would still be an improvement.

It looks like the images in editor\composer\res can either be replaced or overridden using a jar.mn, but I can't find where text_caret.png is referenced. My searchfox-fu isn't strong enough for this one. Gijs, do you see where these are referenced?

Comment 16

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #13)
> Sorry, I didn't realize these were posted when the bug was filed. Though the
> ones that Edge use have a blue border but the attachments here have a black
> border.

Are we sure the color doesn't change with the Windows color scheme or something?

Comment 17

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #15)
> Yeah, that's what it looks like. Though using black here would still be an
> improvement.
> 
> It looks like the images in editor\composer\res can either be replaced or
> overridden using a jar.mn, but I can't find where text_caret.png is
> referenced. My searchfox-fu isn't strong enough for this one. Gijs, do you
> see where these are referenced?

I think we're not even shipping them. Looking on a Windows Nightly build, they're not in resource://gre/res/ , and I don't see them being referenced anywhere.

Instead, I think comment #2 has the right file names, kind of, but we're no longer using text_caret because bug 1210341 updated most of the code references to new files that live in layout/ somewhere and match the packaged file names, but didn't delete the files. Then bug 1221459 removed the remaining installer manifest entries and references, and a bunch of other stuff, but doesn't seem to have removed the actual images.

:TYLin, why are the text_caret*.png images still here? Can they just be removed? (Different bug please if yes!)

Comment 18

[:Gijs (he/him)]

Jared, for the images you *do* want to override and that we *do* ship, see https://dxr.mozilla.org/mozilla-central/search?q=path%3Aaccessiblecaret+path%3Apng&redirect=false

Comment 19

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Those blue caret handles was landed originally by B2G, and now becomes the platform default.

Re comment 17:
> :TYLin, why are the text_caret*.png images still here? Can they just be
> removed? (Different bug please if yes!)
They can be removed. Filed bug 1301325.

Re comment 2:
> Not sure what the best way to fix this is... Seems like these should
> ultimately end up as assets in /[browser|toolkit]/themes. But I suspect
> platform wouldn't want Gecko to have a dependency on Toolkit? Although maybe
> there's some flexibility since it's pref controlled? Have it disabled in
> all.js, and enable it in firefox.js?
> 
> Can the theme jar.mn use the |override| directive for resource://?
> 
> Alternatively it would be nice to pull these from the native OS via
> -moz-appearance, but I assume that's a lot more work.

I think the best approach to fix this is to follow my patch Part 3 in bug 1097398, which customized the caret images for Fennec.  We need to get the desired image asssets, and find the right place to put them.   I don't remember whether resource:// can be overridden. However, since caret images are specified by background-images in CSS rules (see ua.css), we can write new CSS rules to override the images for Windows.

Comment 20

[Krasnaya Ploshchad’]

Attachment: Select text by touch, Free Download Manager 5.1.png

On Windows 10 I found some apps has a different style of touch carets. When I use Free Download Manager 5.1 I found an example. This snapshot is taken when I select text in “Add Download” dialog, I have taken another snapshot of this in attachment 8789703 [details].

Comment 21

[Krasnaya Ploshchad’]

Attachment: Select text by touch, Google Chrome.png

This is touch caret on Google Chrome, looks very same as FDM 5.1

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Testing on my Windows Surface I see that in Edge touch-selection pops up blue monocles, but in Chrome I see the angled teardrop thingies pictured in the attachment in comment 21. We get vertical teardrops. In a Windows app like Notepad I don't get anything at all, and there doesn't seem to be any way to fine-tune the text selection by touch.

Given all this inconsistency I personally am ok with shipping our touch carets shaped as-is so I'm not considering this a blocker for touch. If anybody feels differently feel free to argue your case. I believe the next step on this bug is to get new image assets and pop them in somewhere.

Also updating status flags since the touch carets are currently nightly-only and so they got disabled in 51 as it went to aurora, and are now enabled on Nightly 52.

Comment 23

[Julien Cristau [:jcristau] (back April 22)]

Too late for firefox 52, mass-wontfix.