Checking a page before attaching content script and content style [page-mod]

[CIAvash]

I created an add-on that adds some capabilities to the image view. For
doing this, I had to set "include" to /.*/ and check the page if it is
the image view (by looking for
"resource://gre/res/TopLevelImageDocument.css" in the link tag. This is
the only way that came to my mind).

This means that content script and content style will be attached to
every page so that I can do something on images. Because we can only
test the URL(if I'm not mistaken).

So if there is no other way to do it efficiently, I think we need
something like this in page-mode:
include: /.*/,
checkScriptFile: [data.url('some_file.js')]

And in the checkScript file:
if (this is the page we want) return true;

When checkScript returns true, content script and content style will be
attached.

So what do you think?

[ZER0]

On 7/18/12 4:05 PM, CIAvash wrote:

> I created an add-on that adds some capabilities to the image view. For
> doing this, I had to set "include" to /.*/ and check the page if it is
> the image view (by looking for
> "resource://gre/res/TopLevelImageDocument.css" in the link tag. This is
> the only way that came to my mind).

What about limit your content script to only image's URL? So, you're
applying the content script only if the URL is an image.

> So if there is no other way to do it efficiently, I think we need
> something like this in page-mode:
> include: /.*/,
> checkScriptFile: [data.url('some_file.js')]

> And in the checkScript file:
> if (this is the page we want) return true;

For what I can see, `checkScript` needs to be attached in anycase, if
"this is the page we want" condition have to check the content of the
page, to determined if that is the page we want. So basically,
`checkScript` *is* a "content script", that needs to be attached to
every pages, so nothing is changed.

[CIAvash]

On Wed 18 Jul 2012 07:24:28 PM IRDT, ZER0 wrote:

> What about limit your content script to only image's URL? So, you're
> applying the content script only if the URL is an image.

This is what I wanted to do at first. But some image URLs don't have an
extension(like jpg, png, ...).
Take this Gravatar URL for example:
http://1.gravatar.com/avatar/76fe9416898a9358dcfad18237b3d949?s=200

> For what I can see, `checkScript` needs to be attached in anycase, if
> "this is the page we want" condition have to check the content of the
> page, to determined if that is the page we want. So basically,
> `checkScript` *is* a "content script", that needs to be attached to
> every pages, so nothing is changed.

Yes. But it can be a simple and small condition. And it will prevent
any confliction.
If we don't use a "checkScript", there will be 2 problems:
1. We have to move the condition to the main content script and put the
whole code inside it.(This may not be a problem, but if the code is not
small it might be)
2. Style from content style will apply on every page so we must use a
unique CSS class to prevent confliction.

I don't know how much resource it will use, so I can't say that this is
also a problem or not.

[ZER0]

On 7/18/12 5:33 PM, CIAvash wrote:

>> For what I can see, `checkScript` needs to be attached in anycase, if
>> "this is the page we want" condition have to check the content of the
>> page, to determined if that is the page we want. So basically,
>> `checkScript` *is* a "content script", that needs to be attached to
>> every pages, so nothing is changed.

> Yes. But it can be a simple and small condition.

As soon as the condition needs to check the content of the page, it
really doesn't matter, the script needs to be attached to the page;
therefore will be a "content script".

> And it will prevent any confliction.

What kind of confliction?

> If we don't use a "checkScript",

You can use a "checkScript", but it's nothing more than a
"contentScript". You could use a pageMod with a tiny contentScript that
check your condition, and then attach the bigger contentScript using
`tab.attach`.

> 2. Style from content style will apply on every page so we must use a
> unique CSS class to prevent confliction.

If you're using the "*" in include to filter manually later the page
with JS, then probably you should apply the stylesheet with JavaScript
as well.
We are working on improving `contentStyle`, but from this point of view
it will still behave like now, if you're using "*".

As workaround you could use the tab's title to limit the page where you
attach your content script; but if you need a reliable method I will
suggest to you to use low level APIs to determined if the tab is
displaying an image.

In any case, to me `pageMod` is not the tool you have to use, because it
based on URLs, and your criteria is not URL based. Probably `tabs`
module is more appropriate for what you want to achieve.

Maybe we could think about adding a `mimeType` property in `tabs` API,
in order to check the type of document currently loaded (and with
PDF.js, the image viewer, and so on, it could be useful I guess).

[CIAvash]

On Wed 18 Jul 2012 09:06:08 PM IRDT, ZER0 wrote:

> You can use a "checkScript", but it's nothing more than a
> "contentScript". You could use a pageMod with a tiny contentScript that
> check your condition, and then attach the bigger contentScript using
> `tab.attach`.

This is what I wanted.
But why is there no "contentStyle" key for tabs.attach page mod? There
is only mention of contentScript in the SDK documentation.

> As workaround you could use the tab's title to limit the page where you
> attach your content script; but if you need a reliable method I will
> suggest to you to use low level APIs to determined if the tab is
> displaying an image.

Which APIs should be used for this case?

> In any case, to me `pageMod` is not the tool you have to use, because it
> based on URLs, and your criteria is not URL based. Probably `tabs`
> module is more appropriate for what you want to achieve.
>
> Maybe we could think about adding a `mimeType` property in `tabs` API,
> in order to check the type of document currently loaded (and with
> PDF.js, the image viewer, and so on, it could be useful I guess).

The "mimeType" property would be very nice.

[ZER0]

On 7/18/12 9:37 PM, CIAvash wrote:

>> You can use a "checkScript", but it's nothing more than a
>> "contentScript". You could use a pageMod with a tiny contentScript that
>> check your condition, and then attach the bigger contentScript using
>> `tab.attach`.

> This is what I wanted.

Just to outlined that you don't need a new properties for that, that
`checkScript` is not a new feature, but just another name for
`contentScript`, and you could do something like that already. More or
less. :)

> But why is there no "contentStyle" key for tabs.attach page mod?

No, as I said pageMod are designed around URLs, and the `include`
property was designed to match the @-moz-document / @document css rule:
https://developer.mozilla.org/en/CSS/@document that is currently used by
`contentStyle`.

As I wrote in my previous post, we're currently working on modifying the
platform in order to apply stylesheet in a different way.

If you're interested, there is a wiki page that summarize what are the
current issues and the bug filled in bugzilla to solve them:
https://github.com/mozilla/addon-sdk/wiki/contentStyle-issues

>> As workaround you could use the tab's title to limit the page where you
>> attach your content script; but if you need a reliable method I will
>> suggest to you to use low level APIs to determined if the tab is
>> displaying an image.

> Which APIs should be used for this case?

You could use `window-utils` for instance, in order to obtain the active
browser window, and then the content type of the document loaded.
However, I'm not sure if this will be enough for you � and also, you
will use a low level API that likely will change, so you're at risk. But
except for using the chrome authority or the low level API, I can't
imaging any other approach at the moment. Maybe others could come with
better ideas.

>> Maybe we could think about adding a `mimeType` property in `tabs` API,
>> in order to check the type of document currently loaded (and with
>> PDF.js, the image viewer, and so on, it could be useful I guess).

> The "mimeType" property would be very nice.

Probably will be `tab.contentType`, but yes, something like that. In
that case, could you fill a bug in bugzilla with your scenario and why
it should be useful to have it? Thanks! :)

[CIAvash]

On Thu 19 Jul 2012 01:22:10 AM IRDT, ZER0 wrote:

> Just to outlined that you don't need a new properties for that, that
> `checkScript` is not a new feature, but just another name for
> `contentScript`, and you could do something like that already. More or
> less. :)

Yes. I understood. :)

> No, as I said pageMod are designed around URLs, and the `include`
> property was designed to match the @-moz-document / @document css rule:
> https://developer.mozilla.org/en/CSS/@document that is currently used by
> `contentStyle`.

So I can't use the "page-mod + tab.attach" method. I don't want to
apply the style sheet with Javascript.

> Probably will be `tab.contentType`, but yes, something like that. In
> that case, could you fill a bug in bugzilla with your scenario and why
> it should be useful to have it? Thanks! :)

I have a question:
How should it be used in my case? With page-mod and contentScript, as a
reliable method to know that we are in the image view? If yes, it will
not solve the "attaching" problem.
Or with the tabs module, with tabs ready event and attach method? This
will not solve the problem too, I use contentScriptWhen: "start" in my
add-on, is it possible to achieve this by tabs module?
I also tired tabs ready event to print the document's title, it didn't
work on images but It worked on other tabs.
Even if tabs ready event worked, I couldn't use contentStyle.

I can only think of these two methods to use "tab.contentType" if it
was available. Would there be another way?

But in general I think it is useful to have "tab.contentType".

[Jeff Griffiths]

On Thu Jul 19 03:14:19 2012, CIAvash wrote:
...

> But in general I think it is useful to have "tab.contentType".

I've added this bug, but I would appreciate any additional comments you
might have to be added to the bug so we capture your idea:

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

[ZER0]

On 7/19/12 12:14 PM, CIAvash wrote:

>> No, as I said pageMod are designed around URLs, and the `include`
>> property was designed to match the @-moz-document / @document css rule:
>> https://developer.mozilla.org/en/CSS/@document that is currently used by
>> `contentStyle`.

> So I can't use the "page-mod + tab.attach" method. I don't want to apply
> the style sheet with Javascript.

Then, you can't do much at the moment. As I said, `contentStyle` is only
for `pageMod` because it's URL based (see the @document rule above). So
if you discriminant is not URL, you can't use `contentStyle`, you have
to add the style in the page.

As you can see from the wiki page I gave to you, it's a current limit of
the platform. We're working on it, but at the moment you can't use
`contentStyle` in other way.

> Or with the tabs module, with tabs ready event and attach method? This
> will not solve the problem too, I use contentScriptWhen: "start" in my
> add-on, is it possible to achieve this by tabs module?

I don't think so.

> I also tired tabs ready event to print the document's title, it didn't
> work on images but It worked on other tabs.

Mhm, it could be possible that image react in a different way, and
doesn't fire the proper event. I recall one of our platform guy (Gabor?)
talked about something like that, but I'm not sure.

> Even if tabs ready event worked, I couldn't use contentStyle.

Yeah, that's correct. Because `contentStyle` is URL based, and the logic
you want to apply is not URL based.

> I can only think of these two methods to use "tab.contentType" if it was
> available. Would there be another way?

Nothing that I can think at the moment.

> But in general I think it is useful to have "tab.contentType".

That shouldn't be too hard. I see Jeff already create the bug. :)

[CIAvash]

On Thu 19 Jul 2012 10:18:28 PM IRDT, ZER0 wrote:

> Then, you can't do much at the moment. As I said, `contentStyle` is only
> for `pageMod` because it's URL based (see the @document rule above). So
> if you discriminant is not URL, you can't use `contentStyle`, you have
> to add the style in the page.
>
> As you can see from the wiki page I gave to you, it's a current limit of
> the platform. We're working on it, but at the moment you can't use
> `contentStyle` in other way.

OK. I will try linking my CSS file to the page.

[ZER0]

On 7/19/12 12:14 PM, CIAvash wrote:

> I can only think of these two methods to use "tab.contentType" if it was
> available. Would there be another way?
>
> But in general I think it is useful to have "tab.contentType".

`tab.contentType` property it's landed on master, if you want to play
with it:

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

[CIAvash]

On Thu 02 Aug 2012 06:43:46 PM IRDT, ZER0 wrote:

> `tab.contentType` property it's landed on master, if you want to play
> with it:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=775606

I used it with tabs' ready event and it doesn't work on images, but it
works on 'text/html' content. It is the same thing I mentioned before:

[ZER0]

On Thu Aug 2 17:18:51 2012, CIAvash wrote:

>> `tab.contentType` property it's landed on master, if you want to play
>> with it:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=775606
>
> I used it with tabs' ready event and it doesn't work on images, but it
> works on 'text/html' content. It is the same thing I mentioned before:

yes, they are different issues. The new `tab.contentType` property has
nothing to do with the events for images. My suggestion was to play
with this property in the "checkScript" scenario you mentioned
initially, so you can have a page-mod that check the content type of
the tab and the attach a bigger script only if it's an image. Something
like:

const { PageMod } = require("page-mod");

PageMod({
include: "*",
contentScript: "",
onAttach: function(worker) {
let { tab } = worker;

if (tab && tab.contentType.indexOf("image/") > -1) {
// here you attach your "bigger" script
tab.attach({
contentScript: "document.body.style.borderTop = '10px solid
red'"
})
}
}
});

I also opened a new bug for the "ready" event on images, you can trace
it here: https://bugzilla.mozilla.org/show_bug.cgi?id=779869

I wasn't able to find a bug about it, even if I remember this issue was
already discussed on platform side, in the worst scenario will be
marked as duplicated.

[CIAvash]

I knew I was missing something, I didn't know that worker had a tab
property! :|
When I saw it in your code I looked it up in the documentation and saw
that it was there :/

Thanks! :D

[ZER0]

On 8/2/12 6:30 PM, CIAvash wrote:

> I knew I was missing something, I didn't know that worker had a tab
> property! :|
> When I saw it in your code I looked it up in the documentation and saw
> that it was there :/
>
> Thanks! :D

You're welcome. :) Hope we will fix the "ready" problem as well soon,
but in the meanwhile that workaround should works.