contentStyleFile relative path issue

[Brian King]

I've been playing around with using contentStyleFile in page-mod:

https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/addon-kit/page-mod.html#Styling_web_pages

What I found is that if you have media in the style sheets added that are using relative paths, e.g.

background: rgb(249, 249, 249) url('../../img/mozorg-gradient.png') repeat-x top center;

... they are not found.

What scope are files loaded via contentStyleFile in? How can I include images and other media in these stylesheets? It might get painful to add custom paths to each, especially in the case of stylesheets of 3rd party libraries for example.

--
Brian King

[ZER0]

On 05/28/12 16:17 PM, Brian King wrote:

Hi Brian,

> What I found is that if you have media in the style sheets added that
> are using relative paths

[..]

> ... they are not found.

> What scope are files loaded via contentStyleFile in? How can I include
> images and other media in these stylesheets? It might get painful to add
> custom paths to each, especially in the case of stylesheets of 3rd party
> libraries for example.

So, they are registered as User Stylesheet and we applied a
-moz-document rule on top of them to match the `include` property of
`PageMod`. In order to do that we load `contentStyleFile` and
`contentStyle` in a `data:` URL and pass that URL in the Stylesheet
service. I hope in the future we will be able to skip that step.

Honestly I have no idea at the moment what will be the base URL in that
case for relative images. It could be interesting figure it out.

In the meanwhile, the only approach I can imaging is use the
`contentStyle` to specify the images with relative URL, and
`contentStyleFile` for the rest.

If we don't find later any better approach, we could also replace all
the `url()` value in CSS properties through regexp in order to point to
the `data` folder by default � although it sounds too hacky, and I
really prefer a better approach.

I'm not aware at the moment of a system inside CSS that can set the base
URL (the only thing pop up to my mind is the <base> tag that is useless
in this scenario).

Matteo

[Alexandre poirot]

We should try to get this platform feature implemented ...
  https://bugzilla.mozilla.org/show_bug.cgi?id=737003
... in order to implement contentStyle/contentStyleFile in a non-hacky way.

It is the second bug that would not have exists if we were using such feature:
- contentStyle doesn't match same document than contentScript rules (I think it applies to existing document whereas contentScript doesn't)
- relative URL are broken.

Is there a bug opened for relative url being broken?

2012/5/28 ZER0 <ze...@mozilla.com>

On 05/28/12 16:17 PM, Brian King wrote:

Hi Brian,

> What I found is that if you have media in the style sheets added that
> are using relative paths

[..]

> ... they are not found.

> What scope are files loaded via contentStyleFile in? How can I include
> images and other media in these stylesheets? It might get painful to add
> custom paths to each, especially in the case of stylesheets of 3rd party
> libraries for example.

So, they are registered as User Stylesheet and we applied a
-moz-document rule on top of them to match the `include` property of
`PageMod`. In order to do that we load `contentStyleFile` and
`contentStyle` in a `data:` URL and pass that URL in the Stylesheet
service. I hope in the future we will be able to skip that step.

Honestly I have no idea at the moment what will be the base URL in that
case for relative images. It could be interesting figure it out.

In the meanwhile, the only approach I can imaging is use the
`contentStyle` to specify the images with relative URL, and
`contentStyleFile` for the rest.

If we don't find later any better approach, we could also replace all
the `url()` value in CSS properties through regexp in order to point to

the `data` folder by default – although it sounds too hacky, and I

really prefer a better approach.

I'm not aware at the moment of a system inside CSS that can set the base
URL (the only thing pop up to my mind is the <base> tag that is useless
in this scenario).

Matteo

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[ZER0]

On 05/28/12 20:56 PM, Alexandre poirot wrote:

> We should try to get this platform feature implemented ...
> https://bugzilla.mozilla.org/show_bug.cgi?id=737003
> ... in order to implement contentStyle/contentStyleFile in a non-hacky way.

I wouldn't say it's an hacky way. I mean, the hacky part of the
implementation is the fact that we have to convert the stylesheet file
in a data: URL file (although we have to do that in any case for
`contentStyle`) in order to append at the beginning the `-moz-document`
rules. That's to me it's "hacky".

But even if we don't have that part � let say we have a method to apply
the `-moz-document` without specifying it on the CSS itself � all these
bugs are still present because we use the Stylesheet Service.

The main problem here is that the insertion of scripts with PageMod is
made manually and the styleshees are using the Service, so there are
some differences.

I agree that in our specific case, something that could register a
stylesheet only in a document could be probably easier, because we can
apply manually the same logic we have for the scripts.

I'm a bit afraid, however, that this approach could be slower that what
we have now: at the moment, we register the stylesheet as soon as the
PageMod is created. We don't need to match any "opened" document, so the
CSS is applied immediately as soon as the user open a document that
match the `include` pattern.

However, that doesn't seems the case for the scripts. In regular web
development, when you execute scripts that listen for
"DOMContentLoaded", you can change the content of the page before it is
displayed to the user. Using jetpack, seems not possible: the page will
be displayed and then will be changed like the code runs in parallel.

At the moment is possible fix that behavior using `contentStyle` because
the stylesheets are registered as globals, but I'm worried that this
won't work anymore if we have to apply them manually to a document instance.

I'm not saying I don't want this new method, I want just underline the
needs we have in order to make it.

> - contentStyle doesn't match same document than contentScript rules (I
> think it applies to existing document whereas contentScript doesn't)

Yes, it seems something like that. I guess the bug 708190 will mitigate
that.

> - relative URL are broken.

relative URL are broken in any case, especially for `contentStyle` (not
`contentStyleFile`). Maybe we should mention it in the bug 737003. What
is the base folder for a CSS registered with the Stylesheet Services?
Should we have a way to explicitly force it? I'm thinking about
`contentStyle` specifically.

[Brian King]

On Mon, May 28, 2012 at 8:56 PM, Alexandre poirot <poiro...@gmail.com> wrote:

Is there a bug opened for relative url being broken?

https://bugzilla.mozilla.org/show_bug.cgi?id=759190

--
Brian King | Mozilla Rep
https://reps.mozilla.org/u/brianking/