Closed Bug 1556769 Opened 2 years ago Closed 2 years ago

Text selection background color is gray instead of blue


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

66 Branch
Windows 10
Not set



Tracking Status
firefox-esr60 --- unaffected
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- verified


(Reporter: alice0775, Assigned: smaug)




(Keywords: nightly-community, regression)


(2 files)

Attached image 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:

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

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(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?

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

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

smaug - any clue?

Flags: needinfo?(gandalf) → needinfo?(bugs)

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.

Flags: needinfo?(bugs)

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

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

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.

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.

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

Pushed by
ensure UnsuppressAndInvalidate is called even if paint suppression isn't used, r=emilio
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
QA Whiteboard: [good first verify]

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.

Thank you, Sergiu!

You need to log in before you can comment on or make changes to this bug.