Closed Bug 628863 Opened 13 years ago Closed 13 years ago

Provide an entry point for the disablechrome attribute for add-ons

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b12

People

(Reporter: Felipe, Assigned: Felipe)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

Attached patch PatchSplinter Review
The hidechrome attribute switch should have an easy entry point for add-ons.

My use case is that currently it does an absolute match against the URIs from the inContentWhitelist, but sites like gmail that changes the URI on navigation won't work with that.

An add-on could instead change it to match by domain or host (instead of full path), or always match for app tabs, etc.

This is a simple patch that moves that code into a separate function that an add-on could override.
(Unless add-ons overriding functions is frowned upon.. is it? I guess not)
Attachment #506987 - Flags: review?(gavin.sharp)
Attachment #506987 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/mozilla-central/rev/d6fb5f21cc57
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Just to clarify, since I was a little confused when I first read this .. the bug summary could be read as if this were about an attribute called 'hidechrome', but this is actually about the attribute called 'disablechrome', used on the window element to hide main browser chrome when showing in-content UI like the Add-ons Manager. (Right?)
Correct, I just confused the attribute name
Summary: Provide an entry point for the hidechrome attribute for add-ons → Provide an entry point for the disablechrome attribute for add-ons
Verified fixed by check-in. I will also set the dev-doc-needed keyword because I think it would be good to get this documented for add-on authors.

Robert, as I can recall you have mentioned such a missing feature during your talk at FOSDEM.
Status: RESOLVED → VERIFIED
Flags: in-litmus-
Keywords: dev-doc-needed
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to comment #4)
> Robert, as I can recall you have mentioned such a missing feature during your
> talk at FOSDEM.

Have I? In any case, if there's anything simpler than adding to the whitelist via script, I never saw any notice of it.
Dumb question: what object is the new hideChromeForLocation() method on?
It's in XULBrowserWindow
Hm. I saw that, but was hoping it was subsumed by some other object somehow, because we have essentially no documentation for XULBrowserWindow. I don't even see an explanation in our docs for how you get access to this object.
I think XULBrowserWindow is considered an internal thing, that's why we don't have any docs for it. But it is easy to access from an add-on because it lives in the global context of a browser window, such that extensions that use the traditional browser overlay method to add scripts can access it directly.

Ideally an add-on would extend this function as:

var prevFunc = XULBrowserWindow.hideChromeForLocation;
XULBrowserWindow.hideChromeForLocation = function(aLocation) {
  return (..code goes here..) ||
         prevFunc();
};
So basically, this is a way for add-ons to hook in so they get called when chrome is hidden, by chaining into the XULBrowserWindow.hideChromeForLocation method. Correct?
It allows addons to change the criteria we use for determining whether to hide the navigation toolbar, by overriding that method. If that method returns true, we will hide the chrome. It's called on every page load/tab switch.
This is now documented here:

https://developer.mozilla.org/en/Hiding_browser_chrome
https://developer.mozilla.org/en/XULBrowserWindow

There needs to be a lot more content written to cover the rest of XULBrowserWindow, but at least this particular bug is now addressed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: