1556769 - Text selection background color is gray instead of blue

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Alice0775 White]

Attachment: screenshot

Reproducible: Reproducible only the first time of a session.
This is regression since Firefox66.

Steps To Reproduce:

1. Start Firefox
2. Open about:support (Help – Troubleshooting Information)
3. Attempt to select text by mouse
   --- Observe, Text selection background color, it is gray BUG!
4. Switch other tab and back to original tab
   --- Observe, Text selection background color, it is blue as expected

Actual Results:
Text selection background color is gray.
After switch tabs, it becomes correct color(blue).

Expected Results:
it should be blue.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=33ca2ea6b37064d12c0d4fefc81bf689396a5e57&tochange=9ae7ae0acee4f8807cffaf64fef4f2e3a614b997

Regressed by: 9ae7ae0acee4f8807cffaf64fef4f2e3a614b997 Zibi Braniecki — Bug 1518252 - Block layout on Fluent. r=smaug

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

I have no idea how to even start to debug it :( Is there anyone who may know the highlight code to help me understand why?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Selection is gray when the window is not focused / active. That's the difference between SELECTION_ON and SELECTION_DISABLED:

• https://searchfox.org/mozilla-central/rev/e360889d62bec1737e59dec880f3f1b58f3fdec6/dom/base/nsISelectionController.idl#51

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

Okay, I don't understand why blocking layout on Fluent would cause the change in selection.

smaug - any clue?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I could imagine that there is a bug elsewhere that if window's focus/active state is set before some very core css file is loaded, we then don't end up update selection's styling.
So, I would check what styling causes the coloring, and then compare active/focus state and when that styling is applied.

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

Is this about:support specific? I can't reproduce it on any other document yet.

Comment 6

[Alice0775 White]

about:about page is also affected.
And I got a same regression window:

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

That's helpful! I can see it on a couple other pages too, but only the first time I load the page.

My guess is that it's a race, but I'm still trying to find out where.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f434aa5f257fcd245311a18c49ce4b62625360f

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d790230aff4b20518808af887a51805e348c2988

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1556769, ensure UnsuppressAndInvalidate is called even if paint suppression isn't used, r=emilio

UnsuppressAndInvalidate updates focus state among others, so it needs to be called even if paint suppression itself
isn't used. An example of a such case is when PresShell is created after Document's readyState is already Document::READYSTATE_COMPLETE.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

I wouldn't be surprised if that tiny change causes some test failures. This is really ancient code.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0901390f6a2
ensure UnsuppressAndInvalidate is called even if paint suppression isn't used, r=emilio

Comment 13

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/f0901390f6a2

Comment 14

[Negritas Sergiu, Desktop QA]

Following the STR from the description, I reproduced this issue using Fx 69.0a1 on Windows 10. I can confirm this issue is fixed, I verified using Fx 69.0b13 on the same environment.

Comment 15

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Thank you, Sergiu!