Closed
Bug 332529
Opened 18 years ago
Closed 7 years ago
Run userChrome.js at startup (resp. when loading the main window)
Categories
(Toolkit :: Startup and Profile System, enhancement)
Toolkit
Startup and Profile System
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: zeniko, Unassigned)
References
()
Details
Attachments
(1 file)
3.34 KB,
application/x-xpinstall
|
Details |
XUL applications can be customized in several different ways, from hacking the sources to installing extensions. userChrome.css sits at an intermediary level where for minor modifications neither hacking skills nor installing yet-another-extension are required. The many tip databases concerning CSS hacks are proof of its success. However at the same level there is no corresponding file for JavaScript customization. Many minor needs could be fulfilled through a few lines of code run whenever a window is opened (as userChrome.css is always overlayed). While it is trivial to write an extension to that end, it shouldn't be necessary to install something worth about 10 lines of code for this. userChrome.js could be a great help for developers (for testing hacks without having to modify core code/other extensions) and users (even finer grained control over how their browser behaves). See http://forums.mozillazine.org/viewtopic.php?t=397735 for possible use cases and an extension implementing those "10 lines of code". Steps to Reproduce: 1. Create a file userChrome.js in your profile's chrome folder and add the following line to it: alert("Hello, world!"); 2. Open a new browser/mail/whatever window Expected Result: * A greeting Actual Result: * You need to install an extension first...
Comment 1•18 years ago
|
||
How about a userChrome.xul for overlaying the main window that could also run js or possibly in addition to?
Reporter | ||
Comment 2•18 years ago
|
||
(In reply to comment #1) > How about a userChrome.xul for overlaying the main window that could also run > js or possibly in addition to? The advantage of userChrome.js over userChrome.xul is that there's no or hardly any boilerplate to take into account and that as with userChrome.css you deal with only one language inside the file. This means some less (frustrating) errors a user could run into when applying a hack found on one of the tip pages. OTOH, allowing for an additional userChrome.xul could be nice (otherwise we might quickly see some JS snippets for dynamically loading overlays). What I'm not yet sure of is to whether these files should be applied to all XUL windows (such as userChrome.css) or only to the main application windows (where you'd mostly need them) - i.e. whether we'll require people to always test whether to really apply some code (but allowing them to easily apply code to all windows) or whether they'll have to use a hack for reaching sub-windows (but can apply one-liners without having to care about breaking other windows). I tend to the latter - making the common case easy (while keeping the rare case possible).
Comment 3•18 years ago
|
||
I don't know what the disadvantage is to requiring the user to install an extension for this, especially since -- as you state -- the primary benefit would be for people who are looking to tweak or experiment with browser behaviour. Is there not a security concern to be considered here, where by enabling this behaviour by default it's increasingly possible for a malicious user to hide some nasty functionality in an innocent looking userChrome.js hack? Overall I like the idea for developers, though, as it really makes it easy to do rapid prototyping!
Comment 4•18 years ago
|
||
Sounds like Beltzner wants something very similar to Greasemonkey, but for chrome / browser windows instead of content pages. As for the security argument, you could say the same thing (more or less) for userContent.css hacks, userChrome.css hacks, Stylish user stylesheets or Greasemonkey scripts.
Comment 5•18 years ago
|
||
(In reply to comment #4) > Sounds like Beltzner wants something very similar to Greasemonkey, but for > chrome / browser windows instead of content pages. Sure does, doesn't it? > As for the security argument, you could say the same thing (more or less) for > userContent.css hacks, userChrome.css hacks, Stylish user stylesheets or Well, for the CSS hacks, its not like the function could go and twiddle with the user's disk or other private information, right? > Greasemonkey scripts. And this requires an extension to be installed. Of course, I don't think it's hard to convince a user to install an extension, either (cf: "This will make Firefox work faster!!") My question was really: is this the type of thing we want to enable by default, or should we not be putting a bit to flip (be it extension, about:config pref, etc) that ensures that the user knows what s/he's doing.
Comment 6•18 years ago
|
||
> Well, for the CSS hacks, its not like the function could go and twiddle with > the user's disk or other private information, right? For userContent.css, -moz-binding gives access to plenty of private information (e.g. passwords and cookies). Some people think it shouldn't, see bug 324253. Stylish doesn't distinguish between content CSS hacks and chrome CSS hacks, so it's even worse in terms of what can happen if I can convince you to install my malicious CSS hack.
Reporter | ||
Comment 7•18 years ago
|
||
(In reply to comment #5) > My question was really: is this the type of thing we want to enable by default, > or should we not be putting a bit to flip (be it extension, about:config pref, > etc) that ensures that the user knows what s/he's doing. Note that enabling by default means that the user will still have to first find the profile's chrome folder, rename userChrome-example.js to userChrome.js and then open it in an editor, where s/he will be presented with some warning boilerplate comment. It would IMO be easier to trick the user to install an extension than to add some code to userChrome.js. See also http://wiki.mozilla.org/userChrome.js
Reporter | ||
Comment 8•17 years ago
|
||
This extension implements the suggestion as follows: if the file userChrome.js exists in the chrome folder of a profile, it is run onLoad for every chrome document (i.e. also in Firefox' sidebar, etc.) - thus matching the scope of userChrome.css. Should the file not exists yet, it is created for you (in the end, we'd of course rather add userChrome-example.js to the profile template). Mike: What about adding such functionality to the Toolkit (requesting review due to a lacking ui-review flag)? This would be quite handy for (remote) debugging (since you can easily run code in any context) and of course for testing new functionality to core and extensions. As already mentioned, you can find a respectable bunch of real world snippets at this bug's URL. BTW: The extension having provided such functionality so far has achieved quite some impact (just google for userChrome.js).
Attachment #262436 -
Flags: review?(beltzner)
Reporter | ||
Updated•17 years ago
|
adding this as a Fx built-in is a great idea. however, it should not be added without considering associated utilities. foremost would be @import functions for both scripts and xul, which would take an absolute or relative filename. in exactly the manner that userchrome.css has an @import rule. perhaps there are others as well.
Reporter | ||
Comment 10•17 years ago
|
||
Comment on attachment 262436 [details]
extension containing a component implementing the suggestion
Mike seems overloaded enough without enhancement requests targeted at a tech-savvy minority. Anybody else interested in having this feature: feel free to compile a patch and try to drive it in behind his back. ;-)
Attachment #262436 -
Flags: review?(beltzner)
Comment 11•17 years ago
|
||
1.i'm sure he's capable of addressing his own overload status. 2.the only users of this will be 'tech-savvy'. 3.don't do it at all if you can't do it completely. 4.here's sum code, which you might even recognize; as for patch i'd sure want someone more competent than me submitting them.. ;) function importScript(aPath) { var file = getFile(aPath); setTimeout(function(aFile) { Components.classes["@mozilla.org/moz/jssubscript-loader;1"] .getService(Components.interfaces.mozIJSSubScriptLoader) .loadSubScript(aFile, null); // log it debug("userchrome.js: ", aPath); }, 0, file); }; function importXUL(aPath) { file = getFile(aPath); setTimeout(function() { document.loadOverlay(file, null); // log it debug("userchrome.js: ", aPath); }, 0); }; function getFile(aPath) { if (!/^([\w-]+:)?[\/\\]/.test(aPath)) { var getURLSpecFromFile = Components.classes["@mozilla.org/network/io-service;1"] .getService(Components.interfaces.nsIIOService) .getProtocolHandler("file") .QueryInterface(Components.interfaces.nsIFileProtocolHandler) .getURLSpecFromFile; var chromeDir = Components.classes["@mozilla.org/file/directory_service;1"] .getService(Components.interfaces.nsIProperties) .get("UChrm", Components.interfaces.nsILocalFile); var pathSep = chromeDir.path.match(/[\/\\]/)[0]; aPath = chromeDir.path + pathSep + aPath.replace(/[\/\\]/g, pathSep); } var script = Components.classes["@mozilla.org/file/local;1"] .createInstance(Components.interfaces.nsILocalFile); script.initWithPath(aPath); return (getURLSpecFromFile(script, null)); };
Comment 12•16 years ago
|
||
I fail to see any arguments against integrating this feature. Any argument against it is also an argument against userChrome.css and userContent.css; and there are no plans to remove these. Actually I would prefer to see the patch as userChrome.js AND userContent.js, just like with CSS, one is for customizing Fx itself and one is for modiying every loaded page. Yes, I can install Greasemonkey for it, but Greasemonkey is much more than just that. Arguing, that there is no need for either js, as this can be done by an extension means there is no need for either css either, both could also be done by an extension - but they are not. Whatever reasoning was used to include them in the app itself instead of an extension, the same reasoning would apply to the JS versions, too.
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Comment 13•7 years ago
|
||
With the advent of WebExtensions, the built-in vs. extension discussion is no longer relevant, so could we get this feature re-evaluated by the powers-that-be?
Comment 14•7 years ago
|
||
We will not accept this feature request. In order to support faster refactoring of the browser code, we are trying to stop exposing the browser internals. That is the whole point of webextensions. Adding an alternate mechanism to re-expose the internals goes against this design thrust and is also an easy vector for malware. We may end up in a world where the main browser window doesn't have a single JS scope, for example. (userchrome.css should probably go away for the same reasons, but that will be a different bug)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Comment 15•7 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #14) > We will not accept this feature request. In order to support faster > refactoring of the browser code, we are trying to stop exposing the browser > internals. That is the whole point of webextensions. Adding an alternate > mechanism to re-expose the internals goes against this design thrust and is > also an easy vector for malware. > Correct me if I'm wrong, but we are, however, still planning on exposing browser-UI-level CSS access via the WebExtension themeing API for pre-release channels (a la WebExtension experiments), no? From https://blog.mozilla.org/addons/2017/02/24/improving-themes-in-firefox/: "We also recognize that a property manifest won’t have all the capabilities of direct CSS manipulation, especially during the time we’re expanding coverage to cover the most common use cases. So, for theme authors who need additional capabilities (and are willing to bear the burden of supporting them), we’ll provide an “experimental” section of the manifest to continue to allow direct CSS manipulation of the Firefox UI. This is similar in spirit to WebExtension Experiments, and usage will also be restricted to pre-release versions of Firefox."
Comment 16•7 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #14) > We will not accept this feature request. In order to support faster > refactoring of the browser code, we are trying to stop exposing the browser > internals. That is the whole point of webextensions. Adding an alternate > mechanism to re-expose the internals goes against this design thrust and is > also an easy vector for malware. > > We may end up in a world where the main browser window doesn't have a single > JS scope, for example. > > (userchrome.css should probably go away for the same reasons, but that will > be a different bug) Obviously you can do that, and as a software developer i perfectly understand your reasoning. however i and basically anyone i know still using firefox does so because it has extensions that are not possible in other browsers. I.e. those that require access to *some* browser internals. I strongly believe that unlimited access has to go away for the reasons stated, however it should still be possible to fully customize the browser UI, because that's what sets firefox apart. I.e. web-extensions on steroids, so far i have seen almost nothing of the sort... If you really want to be a chrome/safari/edge clone that is perfectly fine, just don't expect me (or anyone i know) to continue using firefox... imho trying to beat google/apple/microsoft at their own game is a folly. Still for the continued openness of the web i do wish you great success
Comment hidden (advocacy) |
You need to log in
before you can comment on or make changes to this bug.
Description
•