User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
Frequently I update my userContent.css to override foolish webmasters who think
everybody in the world is running 800x600 - I add entries to force their
fixed-width tables to be full width.
When I finish editing my userContent.css file, I have to shut Mozilla down and
restart it to force a reload. It would be nice if there were a better way.
Either Mozilla could load userContent.css when a new window is created (so I
just open a new browser window and close the old), or Mozilla could check the
mtime on the file and load it when it sees the date change.
The ideal solution would be a tool that one could activate to allow you to pick
an item in the window, set the width, and then write the appropriate change to
That, or kill all the idiots who fix-width tables....
Steps to Reproduce:
1. Launch Mozilla
2. Edit userContent.css
None - Mozilla won't read the file until restart
Mozilla ought to read the file when it changes.
I just submitted a bug that has to do with this.
I'm using Mozilla Firebird 0.7
See also bug 78072, same bug for bookmarks.html.
If you are working on patches, it is sensible to turn off the XUL cache in your
Mozilla profile. This means you only have to reopen the relevant window, rather
than restart the entire application, to see UI changes. This is in the Debug |
strict warnings in the Debug prefs.
This bug may still be valid though..
I don't see anything that looks like an XUL cache in about:config on Firebird 0.7
filtering by cache brought up a boolean option about disk cache... maybe that's
Well, I'm not sure how bookmarks and a particular web page got dragged into this
bug. But please don't toss 'XUL cache' into this bug too. That is for UI
developers and is not intended in any way to be an end-user feature. It's an
unstable mode, and pretty much unsupported. It's certainly not a "fix" for anything.
And now back to the original request in comment #0 for dbaron to ponder...
sorry about saying XUL cache
I'm like a 1 year old learning how to talk here,
I was thinking that because it's the userContent.css file... and that is right
next to the userChrome.css file... that they might be loaded at start time, and
cached along with the other user interface stuff...
afterall xul means xml user interface language... and it needs the css to help
define how it is displayed... so why not cache it all together?
There is some sort of cache going on here... and it would be nice to keep it
cached... except for when we want to change it. So... an ability to refresh the
cache (whatever type it may be) with a button click, would be far more pleasing
than restarting the whole browser, or disabling caching completely.
and note, the bookmarks.html file is also in the profile directory... which is
right next to the chrome directory... which has the userContent.css file in it
are two things that spring to my mind after browsing XUL css and mozilla
documents for about a week.
So, bookmarks and a "specific web page" (really an example site of an impossible
to read when zoomed in page). could be fixed by making a few preferences be
reloaded at the push of a button(good compromise hack)... or automatically(tough
hack) or periodically(bad hack)
I don't care if this gets embeded into the trunk, as long as it is available as
push button to reload profile
is how I would redescribe this browser enhansement..
Where in the code is the userContent.css actually loaded? I think the best way
to fix this bug is for an extension to be able to reload the userContent.css
file. So an API to reload the file. This way we could let it be up to an
extension to do the work of reloading and telling the user the file was reloaded etc
(In reply to comment #7)
> Where in the code is the userContent.css actually loaded?
I dont think "LoadSheetFile" is available to an extension, rite?
I agree that's it *particularly* annoying to restart your browser (Mozilla or
Firefox, don't care) EACH time you add or modify a little rule in the
What could I/we do ?
*** Bug 319592 has been marked as a duplicate of this bug. ***
(In reply to comment #9)
> What could I/we do ?
until you or somebody else fixes the issue, you can use the stylish extension currently based at http://forums.mozillazine.org/viewtopic.php?t=327735
works like a charm
Do I need to build an XPCOM component to reload userchrome.css/usercontent.css at runtime?
An extension could be done for it - or ChromEdit or Quickrestart extended to include this feature.
/*start CSS service*/
var sss = Components.classes["@mozilla.org/content/style-sheet-service;1"]
var ios = Components.classes["@mozilla.org/network/io-service;1"]
/* remove old sheet*/
var u = ios.newURI("PATH TO OLD STYLE SHEET", null, null);
/* register new sheet */
var uri = ios.newURI("PATH TO NEW STYLE SHEET", null, null);
Not very difficult to do, actually, if you have worked with Firefox code before. Only left to think of where the current sheet is (most possibly a chrome:// url), and where the new style sheet is (most likely a file:// url, which maybe needs to be loaded into chrome or into memory)... And because it is of no sense to apply the style continuously (this will make us apply lines which are not finished), then we must have a toolbar button / menu command for style update.
Either switch off userChrome and userContent functionality in Firefox completely, or implement it in a way that is easy to use. At last, you must have made it for end users, not for developers, and many of them will find it more comfortable to apply styles without a restart.
>Either switch off userChrome and userContent functionality in Firefox
>completely, or implement it in a way that is easy to use.
I prefer the second choice. What is the path to userContent.css? Together with your code it would be the basis for a simple toolbar button, reloading userContent.css at user's wish without restart.
In fact, WebMail Ad Blocker was created partly due to currently uncomfortable implementation of userContent.css: I don't use it because I have long ago used userContent.css for removing advertisements in my mail.
*** Bug 567736 has been marked as a duplicate of this bug. ***
Note: Chrome also has user stylesheets (through the --enable-user-stylesheet startup option) and detects changes made to <profiledir>/User StyleSheets/Custom.css, meaning you just have to edit and save this file and Chrome will apply the contained css on the fly without restart.
It that may interest people frequently facing this bug (I personnally test my custom css in Chrome, then import it into Firefox), and I think it is a good implementation that could serve as a model for whoever tries to fix this bug in Firefox.
since I started playing around with userContent.css it really got annoying restarting firefox each time I made a change.
With Nick's post (thank you!) I got some inspiration to add a Menu-Entry "Reload User Style" that triggers the re-register of the stylesheet. I assume a firefox with a flat chrome directory (not zip compressed) so that you can patch the browser.xul right away (see attached patch).
Then add the file "sxw-tools.js" (also attached) to the very same directory the browser.xul resides in, restart firefox and you should be presented with a new menu entry as to be seen in the attached screenshot.
Created attachment 631741 [details] [diff] [review]
Created attachment 631742 [details]
Created attachment 631743 [details]
I love when devs spend (10) years ignoring a feature request instead of taking an hour to implement it.
(In reply to M8R-kf8x4n from comment #21)
> I love when devs spend (10) years ignoring a feature request instead of
> taking an hour to implement it.
This is not a helpful comment.
Perhaps you could try to find a good owner for this bug (via inspecting Mercurial logs and talking to people on IRC), or perhaps you could help fix the bug yourself and have someone review your work?
This is not an area of the browser I know at all (I work on mobile), so this represents significantly more than an hour's work for me, but perhaps there exists someone that could fix this in an hour.
Given there are hundreds of thousands of bugs and considerably fewer developers to look at them, I can assure you that no bugs are actively being ignored.
This feature request (and in fact userContent.css as a whole) has been obsoleted by the Stylish extension long ago. Someone in charge could close this bug WONTFIX.
I actually like userContent.css and prefer to keep all of my styles in one file instead of Stylish's sqlite database. I know there's User Style Manager as well, but I see no need for a separate add-on for this basic functionality.
(In reply to ivan from comment #24)
> I see no need for a separate add-on for this basic functionality.
...functionality which is built into competing web browsers.
I don't want to use an extension for this either. userContent.css reload should be achieved through the Firefox developer console (aka command line) (Shift-F2) http://hacks.mozilla.org/2012/08/new-firefox-command-line-helps-you-develop-faster/
Stylish stops being a viable solution for this once you start adding images, since it's not able to load them from the user chrome directory.
I agree that this could be a built-in feature, but the feature is still missing. Therefore, I've installed Stylish and all that is to be seen is an "S" button in the add-ons toolbar, which I guess is meant for "User Styles". The User Styles tab at about:addons is empty.
Is the reloading of userContent.css automatic? Or is it meant to happen via user interaction?
(In reply to waav_zoungla-mozbug from comment #28)
> I agree that this could be a built-in feature, but the feature is still
> missing. Therefore, I've installed Stylish and all that is to be seen is an
> "S" button in the add-ons toolbar, which I guess is meant for "User Styles".
> The User Styles tab at about:addons is empty.
> Is the reloading of userContent.css automatic? Or is it meant to happen via
> user interaction?
Use the proper forum to get help with Stylish. Use this space only to post new info about the bug itself.
Why on earth is this 14 year old bug not fixed? Moreover, this seems to be a windows issue as, if I recall correctly, userContent and userChrome reload on refresh for Linux. On Windows 10 changes require a restart (well, it is windows, so I guess we are lucky a reboot isn't required). Seriously, this isn't a 'developer only' issue, this feature is needed by default in all builds as more and more tweaks to userContent and userChrome are required just to make FF behave correctly.