Open Bug 1292900 Opened 3 years ago Updated 8 months ago

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

Categories

(Toolkit :: General, defect)

Unspecified
Windows
defect
Not set

Tracking

()

Tracking Status
firefox51 + unaffected
firefox52 --- wontfix

People

(Reporter: jimm, Unassigned)

References

(Blocks 3 open bugs)

Details

Attachments

(3 files)

The current touch carets are little blue teardrops, native selection carets are round O's.
[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.
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/accessiblecaret-normal@1x.png 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.
Blocks: windows-10
(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.
(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.
Attached file selection-monocle.zip
we had three resolutions too.
Any CSS/images we add here should probably live in toolkit.
Product: Firefox → Toolkit
OS: Unspecified → Windows
Summary: Firefox touch carets don't match native → Firefox touch carets don't look the same as the native Windows touch carets
Hi :jimm,
Will you help to find someone on this issue?
Flags: needinfo?(jmathies)
(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?
Flags: needinfo?(jmathies)
(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. :-)
Flags: needinfo?(bugmail)
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.
Flags: needinfo?(bugmail)
Stephen, do you know who may have these images?
Flags: needinfo?(shorlander)
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.
Flags: needinfo?(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?
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?
Flags: needinfo?(gijskruitbosch+bugs)
(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?
(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!)
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(tlin)
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
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.
Flags: needinfo?(tlin)
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].
This is touch caret on Google Chrome, looks very same as FDM 5.1
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.
Too late for firefox 52, mass-wontfix.
Blocks: fx-touch
No longer blocks: 1158152
You need to log in before you can comment on or make changes to this bug.