1209192 - URLs in injected CSS files are relative to the CSS file rather than to the page

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect, P3)

Description

[Dan Callahan [:callahad]]

In Chrome, both background-image: url(//example/image.png) and url(https://example/image.png) work.

In Firefox, only the second example, explicitly specifying https://, works.

Test in https://github.com/callahad/webextension-tests/tree/master/background_image

From looking at commits to the Reddit Enhancement Suite, Safari has a similar issue: https://github.com/honestbleeps/Reddit-Enhancement-Suite/commit/58686c405f965f471d2bbbd0eb3348aa139d0ecb

Comment 1

[Kris Maglione [:kmag]]

Documented here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities#Relative_URLs

I'm inclined to mark this invalid. I think our behavior should be the preferred behavior.

Comment 2

[Dan Callahan [:callahad]]

Re-reading this, I guess I'm fine with marking this as wontfix.

Restating the bug for clarity: referencing a resource as `//example.com/foo` will expand to `moz-extension://example.com/foo`, which is an invalid scheme for that URL. This happens because the injected CSS file's scheme is `moz-extension:`, rather than the more common `http:` or `https:`.

Comment 3

[Potch [:potch]]

Do we have a solution for protocol-agnostic absolute paths then? The common way to reference a resource absolutely on a domain that's both http and https is //example.com/foo, which ensures that the protocol matches and avoids mixed content problems. Is there another solution for that if this is WONTFIX?

Comment 4

[Kris Maglione [:kmag]]

Just always load resources from HTTPS.

Comment 5

[Tomislav Jovanovic :zombie]

4 years later, not sure we need docs specifically for extensions, that's just how css url resolution works in all contexts.