Open Bug 1661041 Opened 4 years ago Updated 4 years ago

font visibility doesn't work in sandboxie

Categories

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

80 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: thorin, Unassigned, NeedInfo)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

reporting for someone else: I'll get them to provide more details. This would also affect RFP users in FF80+ using sandboxie (and maybe other sandboxing apps)

Setting the whitelist works but the visibility pref doesn't. It should be mostly a font reduction based on hardcoded lists so I don't understand why that shouldn't work with sandboxie.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core
Version: 78 Branch → 80 Branch
Flags: needinfo?(jfkthame)

Is it possible that sandboxie (about which I know nothing...) is blocking DirectWrite from working, and we end up falling back to the GDI-based font backend? If so, that could explain this, as the GDI backend doesn't currently support the visibility feature.

And if that's the case, it suggests either a deeper underlying Firefox bug (why does DWrite fail in this environment?) or that sandboxie isn't adequately compatible with modern Windows APIs.

What does the user's about:support indicate about DirectWrite?

Flags: needinfo?(jfkthame) → needinfo?(simon.mainey)

Hi Jonathan,

Simon reported this for me. Thanks for taking a look at it.

about:support says DirectWrite: true (6.2.9200.22902) but I'm not sure if that means it's actually working or just enabled ie sandboxie is somehow blocking DirectWrite from working but Firefox is unable to detect that.

I saw that there's a MOZ_LOG for this fonts stuff but I couldn't find the exact name to use to enable those logs. Do you know?
Maybe that could help indicate what the problem is.

Let me know if there's anything else I can do to help.

Are there any plans to support the visibility feature in the GDI backend anytime soon?

Flags: needinfo?(jfkthame)

I think we can confirm whether dwrite is being used if you check about:telemetry#histograms-tab_search=dwrite; this should show results related to DWRITEFONT measurements if the DirectWrite backend is active.

Not sure about the future of the GDI backend; it wouldn't be hard to add some visibility support there, I think, but on the other hand I also think there's a desire to deprecate and finally remove it rather than go on supporting it indefinitely.

Flags: needinfo?(jfkthame)

Ok, I checked it in fresh FF81 beta profiles (because extended telemetry is force-disabled in Release).

without sandboxie:

parent process:

DWRITEFONT_DELAYEDINITFONTLIST_TOTAL
1 sample, average = 128, sum = 128

14 | 0 0%
50 |######################### 1 100%
180 | 0 0%

DWRITEFONT_DELAYEDINITFONTLIST_COUNT
1 sample, average = 136, sum = 136

32 | 0 0%
101 |######################### 1 100%
319 | 0 0%

DWRITEFONT_DELAYEDINITFONTLIST_COLLECT
1 sample, average = 127, sum = 127

14 | 0 0%
50 |######################### 1 100%
180 | 0 0%

content process + extension process: exact same as in the parent process


with sandboxie:

parent process:

DWRITEFONT_DELAYEDINITFONTLIST_TOTAL
1 sample, average = 345, sum = 345

50 | 0 0%
180 |######################### 1 100%
647 | 0 0%

DWRITEFONT_DELAYEDINITFONTLIST_COUNT
1 sample, average = 136, sum = 136

32 | 0 0%
101 |######################### 1 100%
319 | 0 0%

DWRITEFONT_DELAYEDINITFONTLIST_COLLECT
1 sample, average = 311, sum = 311

50 | 0 0%
180 |######################### 1 100%
647 | 0 0%

content process:

DWRITEFONT_INIT_PROBLEM
4 samples, average = 2, sum = 8

1 | 0 0%
2 |######################### 4 100%
3 | 0 0%

extension process:

DWRITEFONT_INIT_PROBLEM
1 sample, average = 2, sum = 2

1 | 0 0%
2 |######################### 1 100%
3 | 0 0%

With or w/o sandboxie, there's nothing under "dynamic process" and "gpu process".

As you can see DWRITE fails to init in the content and extension process when Firefox is sandboxie-d.
To me that indicates that sandboxie isn't fundamentally broken in a way that prevents DirectWrite from working but rather that there's a difference in how DWrite is initialized in the parent process vs content/extension process(es). Hopefully that's something that can be "fixed" in Firefox.

I also noticed that the numbers differ in the parent process in DELAYEDINITFONTLIST_TOTAL and DELAYEDINITFONTLIST_COLLECT:

without sandboxie: 14, 50, 180
with sandboxie: 50, 180, 647

I don't know what these numbers mean but I guess they're probably not that important.

Flags: needinfo?(jfkthame)
Flags: needinfo?(simon.mainey)
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.