706209 - have a way to style the selection in inactive windows (apply ::-moz-selection or add similar but different way)

Status: NEW

(Core :: Layout: Text and Fonts, enhancement)

Description

[Artur Adib]

It'd be nice if we could combine moz-selection with moz-window-active/inactive, so that we could override FF's default behavior of making selected text both opaque and gray in inactive windows (at least on OS X).

This would be useful for our pdf.js project, where we have a transparent layer of text on top of a canvas used for faking text selection: Currently, when the user inactivates a window the forced opaque-gray selection hides the canvas content behind it.

Here's a discussion on this by someone else:

http://css-tricks.com/9288-window-inactive-styling/

Thanks!

Comment 1

[Boris Zbarsky [:bzbarsky]]

This seems to be quite purposeful.  In particular, nsTextPaintStyle::InitSelectionColors does this:

3447      if (selectionElement &&
3448          selectionStatus == nsISelectionController::SELECTION_ON) {

around looking up ::selection styles.  When the window is active, the selectionStatus is SELECTION_ON.  Otherwise it's SELECTION_DISABLED, at least on Mac.

This behavior was introduced by bug 56314, looks like.  Masayuki, why is that check there?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Because the -moz-selection is for specifying normal selection styles rather than other styles (including disabled). If we apply the specified style to -moz-selection simply, we always paint the selection on some sites as active even if the window is inactive.

We can think that the inactive selection style is another feature, so, different from normal selection. If the suggested trick is needed by web developers, I think there should be -moz-selection-disabled or something. If so, we can paint the disabled selection even on such pages.

Comment 3

[Artur Adib]

I can't claim I understand the rationale for not preserving the -moz-selection style in inactive windows (somehow WebKit gets away with preserving it), but anyway another solution that would work for us is to combine -moz-selection and -moz-window-inactive as suggested in the link above:

::-moz-selection:-moz-window-inactive {
  background: rgba(255,0,0,0.3);
}

Comment 4

[Boris Zbarsky [:bzbarsky]]

That won't help; the code that looks at the moz-selection value has no idea what selector was used to apply it.

Comment 5

[Artur Adib]

Bummer. I guess we're stuck with gray-and-opaque then?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, we could add ::-moz-disabled-selection.

Comment 8

[Tim Down]

There is a related Firefox bug where the selection always appears inactive in an iframe that has been dynamically created by script, thus preventing any styling of the selection in such an iframe:

http://stackoverflow.com/questions/6730814/

Comment 9

[Aaron Simmons]

This behavior becomes a real problem when you combine it with bug 554039.  That is, we could work around the inability to style the inactive window selection color by making that window active, but bug 554039 prevent that.

For more info see these discussions: 
    http://stackoverflow.com/questions/10502099
    http://stackoverflow.com/questions/10501381

Comment 10

[Julian Viereck]

(In reply to Boris Zbarsky (:bz) from comment #6)
> Well, we could add ::-moz-disabled-selection.

Should a separate bug be opened to implement ::-moz-disabled-selection?

Comment 13

[Thomas Wisniewski]

This is called ::inactive-selection in CSS pseudo-elements level 4: https://drafts.csswg.org/css-pseudo-4/#selectordef-inactive-selection

I'm guessing that it would be best to hide this being a pref rather than adding a new ::-moz-inactive-selection for consistency, yes? Can you think of a reason to avoid implementing this for now, pref or not?

Comment 14

[Boris Zbarsky [:bzbarsky]]

That's a question for dbaron; I don't know how stable this spec draft is.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not sure how stable the spec draft is, but the feature seems (assuming ::selection is complete!) relatively straightforward, so it seems reasonable to implement behind a pref.  Having an implementation also makes the feature more stable.