Selection hides selected text (mac only) in fancy selection demo

NEW
Assigned to

Status

()

6 years ago
6 years ago

People

(Reporter: davida, Assigned: jfkthame)

Tracking

22 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
This demo (http://dropthebit.com/demos/fancy_input/fancyInput.html) works great, except that on Mac/Gecko (both 19 and 22.0a1 nighty), the selection hides the selected text.  The main developer says the bug doesn't exist for Windows, and it doesn't exist on Chrome/Mac.

:tn suggested filing a bug, hence this.

Also filed as a bug in the demo site's repo: https://github.com/yairEO/fancyInput/issues/14
(Reporter)

Comment 1

6 years ago
Created attachment 720067 [details]
Screenshot showing bug with first word selected
Jonathan, do you know if the selection colors of the text, the highlight and the text itself, are just the same here? Or is it an issue with painting?
Flags: needinfo?(jfkthame)
(Assignee)

Comment 3

6 years ago
AFAICS from a brief look at the page, the selection highlight is being rendered by an <input> element that is styled with color:transparent and overlays (z-index:2) the separate <div> containing the text (in single-letters <span>s) that's actually being displayed.

So when some of the text of the <input> element is selected, I'd expect that selection is painted with a solid background color, and then the text itself is drawn on top of the selection background - but as the text color is transparent, that doesn't produce anything, and we're left with just the background color. But as the <input> has been explicitly placed in front of the <div> that contains the visible text, it naturally overpaints it. IOW, I think Firefox is behaving as designed.

I haven't compared the behavior on Windows, but in Chrome/Mac it looks like the selection background is being painted with opacity:0.5 or something like that, so that the text behind it still shows through, whereas Gecko is painting the selection background with an opaque color.

Maybe we should be painting a non-opaque selection background - but I'd also note that the underlying design of this demo is fundamentally flawed, and it will not work "correctly" in the general case. Just try entering some text in Arabic or Devanagari into that input field...
Flags: needinfo?(jfkthame)

Comment 4

6 years ago
the input color is transparent and I think it doesn't show up when selected. seems like stuff that shouldn't have changed in latest Firefox, did. (I don't see this on my PC / WIN7 / FF19)
Are you saying that it worked differently in an older version of Firefox?
(Assignee)

Comment 6

6 years ago
Created attachment 720324 [details] [diff] [review]
give selection background 2/3 opacity, so that what's behind selected text can still be seen

Here's a proof-of-concept patch that aims to give the selection background partial opacity, if the color we get from the platform is fully opaque. With this, the 'fancy selection' demo works, although what it's attempting to do is still fundamentally flawed, IMO. Still, I think it might make sense to take a change along these lines in Gecko, as it makes selection of text over a background such as an image look a little less stark.
(Assignee)

Updated

6 years ago
Assignee: nobody → jfkthame
(Assignee)

Comment 7

6 years ago
Try selecting the text in http://people.mozilla.org/~jkew/select-over-bg.html in Firefox vs Chrome or Safari (on OS X) to see the difference between an opaque and semi-transparent selection background. With the above patch, Firefox's behavior becomes more like webkit's.
(Assignee)

Comment 8

6 years ago
(In reply to yair even or from comment #4)
> the input color is transparent and I think it doesn't show up when selected.
> seems like stuff that shouldn't have changed in latest Firefox, did. (I
> don't see this on my PC / WIN7 / FF19)

Mac and Windows have fundamentally different conventions for selection highlighting, so it's not really useful to compare. Comment #0 points out that this "problem" is on Gecko/Mac, and -not- on Windows.
(Assignee)

Comment 9

6 years ago
Tryserver run with the experimental patch from comment 6. I have -not- tested this on non-Mac platforms to see what the effect may be there.
You need to log in before you can comment on or make changes to this bug.