Local mirroring (experimental feature) breaks web fonts

[gorhill]

Might be related to https://code.google.com/p/chromium/issues/detail?id=308768, have to look more in details.

[ghost]

Might explain why Rockstar GTA Social Club started having broken fonts.

That being said, ever since I've gotten Chrome 38, I've had lots of issues
browser-wide, not just uBlock as disabling it would fix them in that case.

On Thu, Oct 9, 2014 at 4:00 PM, Raymond Hill [email protected]
wrote:

Might be related to
https://code.google.com/p/chromium/issues/detail?id=308768, have to look
more in details.

—
Reply to this email directly or view it on GitHub
gorhill/uBlock#291.

[gorhill]

This site: http://socialclub.rockstargames.com/games?

I'm trying it, and I don't see font problems. Is there a specific page where the problem occurs?

[kurtextrem]

In case it helps: https://keep.google.com/
Doesn't "break" the page, but the custom fonts

[gorhill]

@kurtextrem : Yes, this one I see the problem, and the typical error message at the console:

Redirect at origin 'https://fonts.gstatic.com' has been blocked from loading by Cross-Origin Resource Sharing policy: Received an invalid response. Origin 'https://keep.google.com' is therefore not allowed access.

[ghost]

http://socialclub.rockstargames.com/

The font gets bigger if I toggle "Experimental Features"

Site is still usable.

Note that I have crap ton of addons, but the difference is seen for me just
toggling that, and I see it "mirrors" jQuery and webfont.js from
ajax.googleapis.com.

On Thursday, October 9, 2014, Jacob Groß <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

In case it helps: https://keep.google.com/
Doesn't "break" the page, but the custom fonts

—
Reply to this email directly or view it on GitHub
gorhill/uBlock#291 (comment).

[gorhill]

@CODYQX4 Ok I understand why the difference. I am guessing you are not using "Fanboy's Social", which blocks apis.google.com/js/platform.js, which I think ultimately causes web fonts to be loaded.

[ghost]

I am using that list. I'm using ALL lists of uBlock except the "regional"
ones.

I also have HTTP Switchboard, but again it works without mirroring enabled
despite my complex extension configuration.

On Thu, Oct 9, 2014 at 4:31 PM, Raymond Hill [email protected]
wrote:

@CODYQX4 https://github.com/CODYQX4 Ok I understand why the difference.
I am guessing you are not using "Fanboy's Social", which blocks
apis.google.com/js/platform.js, which I think ultimately causes web fonts
to be loaded.

—
Reply to this email directly or view it on GitHub
gorhill/uBlock#291 (comment).

[gorhill]

It's rather technical, but as far as I can make sense of this, it does look like this might solve the problem here: https://code.google.com/p/chromium/issues/detail?id=308768#c29

[gorhill]

@CODYQX4 I am confused. I don't see the problem on Rockstar, and I don't see web fonts loaded from the current list of candidate CDNs. The request log shows that the fonts are served by the site itself, not a 3rd-party.

[ghost]

Maybe it was them, because all of a sudden I have mirroring on and the
font works again.

I was having Dropbox issues that magically went away as well.

On 10/9/14, Raymond Hill [email protected] wrote:

@CODYQX4 I am confused. I don't see the problem on Rockstar, and I don't see
web fonts loaded from the current list of candidate CDNs. The request log
shows that the fonts are served by the site itself, not a 3rd-party.

---

Reply to this email directly or view it on GitHub:
gorhill/uBlock#291 (comment)

[gorhill]

@CODYQX4 I recently pruned the number of candidate CDNs to mirror, I found this was causing problems -- actually what I pruned was not even CDNs, I just thought it would be safe to mirror them. I really have to stick to mirroring resources which can be safely assumed to be immutable. By disabling/enabling mirroring you forced a flush of the local mirrored resources. Probably you had one which is no longer candidate for mirroring.

[gorhill]

Local mirroring works all fine in Firefox, fonts are not broken -- unlike with Chromium: Test case.

This is the confirmation I was looking for, that the issue lies with Chromium.

[Deathamns]

Try using object URLs instead of base64 encoded data:URIs.
You can set responseType to blob on the XHR, and create an object URL for the response blob, which can be redirected to (not sure if it will work, just an idea).

[gorhill]

I remember reading about object URL, but this sentence turned me away from it:

The URL lifetime is tied to the document in the window on which it was created

Does not quite work for uBlock, as the data is fetched from the background page, and the redirection is done from within the background page context, not the document on which it is meant to be used.

[Deathamns]

That sentence only tells about the lifetime of the URL. Meaning, the resulted blob: URL will be accessible in the browser until you don't disable the extension (i.e., "close the window") or kill it with revokeObjectURL.

But see for yourself by running this code in the console of the extension's background page:

var xhr = new XMLHttpRequest();
xhr.open('get', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', true);
xhr.onload = function() { console.log(URL.createObjectURL(this.response)); };
xhr.responseType = 'blob';
xhr.send();

And open the printed URL in a new tab. Then reload the extension, and refresh the tab (it won't load anymore).

So, the only question is, whether it's possible to redirect requests to a blob: URL.

[gorhill]

Hmm, that's right, I guess I am reading that wrong, I had in mind the object URL had to be created on the page for which it was meant to be used.

I will see if that work.

[gorhill]

• blob:-redirect initiated by webRequest API is blocked
• Cannot redirect to blob URL in background script