Windows servo UI missing elements

[jonathandturner]

When I open a recent Servo for Windows nightly, the UI shows this at the top:

Instead of the expected browser.html chrome.

[emilio]

Seems that this may be related with the font stuff?

[jonathandturner]

It's possible these are related, but the elements here aren't font elements but other UI elements.

[codec-abc]

Can you add detail to the bug please? I can't reproduce with neither the nightly nor compiling servo myself. By the way I am running Windows 10.

[KiChjang]

I can confirm that it also displays this on my Windows 10 laptop. My Linux version of the nightly works fine though.

[atouchet]

I just tested the latest nightly build with Windows 10 and I am still seeing UI issues.

[jonathandturner]

Right - I'm seeing the same as @KiChjang and @atouchet.

Other details:

• Running Windows 10
• Running inside of VMware Fusion on a macOS
  • Using the "VMware SVGA 3D" driver

[codec-abc]

Thanks, about your previous comment are you sure the symbol or the UI aren't made of "characters" because they look like missing characters that I have on other pages (for example, the Chinese character ones at the bottom of the servo web page). On my home PC I can reproduce the issue but it is weird because the source code does not even display those characters in Chrome and Firefox. So maybe it is just some weird characters that are not in the font packaged with Windows by default?

EDIT : On my home computer they display nicely in Firefox and Chrome but not in Servo. So the bug is still there but it looks like a font issue to me. I confirmed this in Chrome, because if I toggle off the style 'font-family : FontAwesome' then it render a square like Servo does.

[jonathandturner]

Leaving notes here as I look around.

I noticed that if I install FontAwesome as a system TTF font, it worked fine. I reconverted it to woff, and the result was a little bigger than the one currently in the repo. Sure enough, when I tried the new woff, that also worked for me. Maybe the one that's there now was missing some sigils?

Update is here: browserhtml/browserhtml#1272

[codec-abc]

Would you mind checking how it renders on FF or Chrome while not having FontAwesome installed system wide? On my home computer the browser.html page render fine in Chrome and Firefox but not in Servo. Then, if it some missing sigils why it works on FF & Chrome and Linux and MacOS and not servo?

[jonathandturner]

@codec-abc - like I said, I don't know why updating the woff fixes the issue on Windows. I don't understand the code well enough. I was just experimenting to see if I could fix it.

[codec-abc]

I opened the 2 woff files (the original one and the one repackaged by you) with fontforge and both contains the glyphs used by the Servo's UI. I have difficulties finding the code that does the work of reading and parsing the woff file.

EDIT: After quite a few searchs I found that the problem seems to be located here. It looks like that the original version cannot be loaded for some reason.

[codec-abc]

I tried to reproduce the issue by creating a small repo containing the code that I think cause the problem. Basically, I read a woff file as a Vec pass it through fontsan (a font sanitizer library) and feed the result to dwrote (a DirectWrite wrapper). Strangely enough it managed to read both the original woff file and the a "fixed" one. Yet yesterday a breakpoint was only hit here with the original font file. I am starting to run out of idea to diagnose further this issue so if anyone has some tips on the subject I would gladly take them.

[codec-abc]

Some update: My previous message was plain wrong because of a breakpoint hit in Visual studio while the underlying code was not run. That would be funny if only I didn't lost so much time chasing a bug in place where the code actually works. Using good old println! instruction I find the place where the code differ when using the original font vs the "fixed" one. It is right here and it make much more sense as a comment indicate that some external crate only support some "things" on mac. Commenting the two if in the methods make the original font works. But that does not seems the right things to do. So now I have to understand the purpose of those 2 if and the intended behavior and how to fix it for windows.

[codec-abc]

I have understood the problem quite well. Those 2 checks (here and here) prevent to create a FontInfo structure where we wouldn't be able to return a font family name and a font face name. This is because the underlying library called truetype is not able to parse all the records properly. The proper things to do would be to add the missing piece in truetype and then remove the checks. But please note that the checks seems to not work properly even now. With the modified font file by @jonathandturner that pass the checks and display the missing UI elements I have a font family name and a font face strings of < unsupported > which is the default value for things that the library is not able to parse.

EDIT: The modified woff file is able to pass the check because when it was regenerated a "macintosh english" record was added.

[codec-abc]

I think the PR made to remove this from the windows blockers is great but the underlying issue is still there. As such, I think it would be better if we would leave this open and remove this issue from the windows blockers. Do you agree?

[jonathandturner]

@codec-abc yes. Actually, do you want to open a new issue that's specifically that we can't load the old woff file? That way we can track it as a woff loading issue instead.

[codec-abc]

@jonathandturner I created #16078. This one can remain closed.

[atouchet]

This is an issue again with the latest nightly build.

[atouchet]

@jonathandturner I updated Servo's version of Browser.html and it seems to have re-broken this in the process. Do you have an idea of whether this would be related to the Font Awesome WOFF file change you made or something else?

Edit: I verified that the WOFF file got reverted and is the problem here. I made browserhtml/browserhtml#1308 to see if re-applying the file change fixes things.

[atouchet]

Whoops, should probably close this after it's fixed in Servo itself.