Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

contentStyle issues 

ZER0 edited this page · 11 revisions

Overview

In Add-on SDK we introduce contentStyle and contentStyleFile as options for page-mod. Those feature gives the capability to applying a stylesheet to all documents that matches the include pattern.

As described in the original bug, contentStyle and contentStyleFile are implemented as User Stylesheet using the Stylesheet service rather than document stylesheets for several reasons.

Protected from introspection

User Stylesheet are protected from introspection by the page. It means, a page can't detect the stylesheet, remove it, or modifying it in any way.

Using a document stylesheet a website could be easily detect which add-on the user has, reverting the changes, modifying the CSS rules on the fly.

Overriding page stylesheet

User Stylesheet can overrides page's stylesheet and inline stylesheet as well, when !important is used. So the author the Add-on can be sure that this style is applied, no matter what.

Using a document stylesheet, an inline stylesheet or another stylesheet added later, could always override the Add-on rules for the same elements.

Timing

User Stylesheets are registered before any document is loaded. They will applied with all the rest of the stylesheets, so the users will see immediately the add-on changes as soon as the document is displayed, avoiding "flickering" effect.

Issues

Comparing to the alternative of document stylesheets, the User Stylesheet and the Stylesheet service is definitely the right direction for an Add-on.

However, even if they following the standards, the behavior of User Stylesheets seems counterintuitive for some developers, where they expect for instance, to have the same behavior of the Style Editor, that uses document stylesheet instead.

In addition, in order to applying the document filtering, we have to dynamically add the [-moz-document] rule to any contentStyle and contentStyleFile, and because the Stylesheet service requires a URL, we have to convert in a data: URL. This is not only a bit hacky, but more important it breaks relative paths.

What the Add-on developers expects?

  1. The contentStyle and contentStyleFile rules should [overrides by default][bug 773602] the rules for the same element contained in the document stylesheets and the stylesheet inline.

  2. The relative paths in contentStyleFile should works as expected, so if the css is contained in the data/ add-on folder, that should be the base URL for relative path.

  3. The page shouldn't be able to detect neither modifying the CSS rules added by contentStyle and contentStyleFile

  4. The contentStyleFile and contentStyle should be applied immediately to a document when is loaded, before it was displayed the first time, to avoid the "flickering" effect. The user should see the document already modified by the Add-on.

How to achieve that?

We should continue to use the Stylesheet service, in order to cover the point 3. If AUTHOR_SHEET type will be supported by Stylesheet service we could have the exact behavior of the Style Editor without the problem of introspection.

To avoid to break the paths in contentStyleFile, we should be able to pass the original URI to the Stylesheet service instead convert it in data: URL.

For accomplish that, Stylesheet service should provides a method to register a stylesheet passing a second parameter that is the -moz-document filtering rule; or provides a method to register a stylesheet to a given document.

It's a good approach if we are sure that we don't have problem with memory/performance, and if there is no timing issue: because we need a document instance, the idea is registering the stylesheet at run time for every document as soon as we receive the document-element-inserted notification. However, similar operation on JS side gives to us the "flickering" effect mentioned before.

If we can avoid any timing issue, then offer a way to apply user agent stylesheet on a given document it's probably the best approach, because we can offer a consistent solution for both contentStyle* and contentScript*.

Bugs

Discussion

Something went wrong with that request. Please try again.