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)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 4.0b12
People
(Reporter: Felipe, Assigned: Felipe)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
1.55 KB,
patch
|
Gavin
:
review+
Gavin
:
approval2.0+
|
Details | Diff | Splinter 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)
Updated•13 years ago
|
Attachment #506987 -
Flags: review?(gavin.sharp) → review+
Updated•13 years ago
|
Attachment #506987 -
Flags: approval2.0+
Assignee | ||
Comment 1•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d6fb5f21cc57
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Comment 2•13 years ago
|
||
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?)
Assignee | ||
Comment 3•13 years ago
|
||
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
Comment 4•13 years ago
|
||
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
Comment 5•13 years ago
|
||
(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.
Comment 6•13 years ago
|
||
Dumb question: what object is the new hideChromeForLocation() method on?
Assignee | ||
Comment 7•13 years ago
|
||
It's in XULBrowserWindow
Comment 8•13 years ago
|
||
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.
Assignee | ||
Comment 9•13 years ago
|
||
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(); };
Comment 10•13 years ago
|
||
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?
Comment 11•13 years ago
|
||
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.
Comment 12•13 years ago
|
||
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.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•