Closed Bug 208641 Opened 21 years ago Closed 7 years ago

Way to force reload of userContent.css at run time

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: david.hagood, Unassigned)

References

Details

Attachments

(3 files)

A Patch for adding the menu entry and the JavaScript file
1.07 KB, patch
Details | Diff | Splinter Review
sxw-tools.js JavaScript file for reloading the userContent.css
1.17 KB, application/octet-stream
Details
The result
24.55 KB, image/png
Details
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 userContent.css. That, or kill all the idiots who fix-width tables.... Reproducible: Always Steps to Reproduce: 1. Launch Mozilla 2. Edit userContent.css 3. Actual Results: None - Mozilla won't read the file until restart Expected Results: Mozilla ought to read the file when it changes.
->Style System
Assignee: general → dbaron
Component: Browser-General → Style System
OS: Linux → All
QA Contact: general → ian
Hardware: PC → All
Depends on: 179006
I just submitted a bug that has to do with this. I'm using Mozilla Firebird 0.7 RelatedBug: http://bugzilla.mozilla.org/show_bug.cgi?id=215462
Blocks: 215462
See also bug 78072, same bug for bookmarks.html.
from: http://www.gerv.net/software/patch-maker/build-mode.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 | Networking prefs panel. Also, if you are changing JavaScript, turn on JavaScript 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 related?
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 Overlays. and diffs 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 an extension... 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? http://lxr.mozilla.org/mozilla/source/layout/style/nsLayoutStylesheetCache.cpp#189 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 userContent.css 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
Assignee: dbaron → nobody
QA Contact: ian → style-system
Do I need to build an XPCOM component to reload userchrome.css/usercontent.css at runtime? Or there is a JavaScript function available for doing it? An extension could be done for it - or ChromEdit or Quickrestart extended to include this feature. Best regards.
I think applying user styles at runtime is a quite worthy demand. Being a user of custom styles means a lot of testing. To do a restart for every new line of code is an uncomfortable practice. JavaScript can do the style change on the fly, very nicely, for example like this: /*start CSS service*/ var sss = Components.classes["@mozilla.org/content/style-sheet-service;1"] .getService(Components.interfaces.nsIStyleSheetService); var ios = Components.classes["@mozilla.org/network/io-service;1"] .getService(Components.interfaces.nsIIOService); /* remove old sheet*/ var u = ios.newURI("PATH TO OLD STYLE SHEET", null, null); if(sss.sheetRegistered(u, sss.USER_SHEET)) { sss.unregisterSheet(u, sss.USER_SHEET); } /* register new sheet */ var uri = ios.newURI("PATH TO NEW STYLE SHEET", null, null); if(!sss.sheetRegistered(uri, sss.USER_SHEET)) { sss.loadAndRegisterSheet(uri, sss.USER_SHEET); } 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.
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.
Gentlemen, 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.
Attached image The result —
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.
(In reply to David Rankin from comment #30) > if I recall correctly, userContent and userChrome reload > on refresh for Linux. It is not, you have to quit Firefox and start it again for any change to userContent.css to be picked up on Linux as well. It would be great to change this, hopefully someone can pick up Simon Wilpers work and automate it.
I am currently on Firefox Nightly 57.0a1 (2017-09-20) (64-bit) and my userChrome.css does update without restarting Firefox. I just need to close and reopen the tab. Refreshing the page (even with forcing a cash clear) does not work. It seems like this has been fixed?
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build 20171005220204 Opening a new tab or window does reflect changes in userContent.css now. I haven't stumbled onto something that does the same for userChrome.css.
(In reply to Gingerbread Man from comment #33) > Opening a new tab or window does reflect changes in userContent.css now. I can confirm this with Firefox 56.0 on Debian GNU/Linux (sid). Changes to userContent.css is pickup up by simply opening a new window, I don't have to close Firefox down completely. Great!!
See Also: → 1409065
Closing as WORKSFORME because it was fixed by some unknown patch. Tentative range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fe22af79bacf6db526737536eab551caf68ba440&tochange=f985243bb630b2c78cd57731c8d8ab191aa09527 Bug 1409065 filed for the userChrome.css equivalent, because none existed from what I could find.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
It does get reloaded for a new window, but not a new tab in an existing window, nor for existing tabs, even if I reload them. Would be nice if that worked, too.
(In reply to Adam Sjøgren from comment #34) > Changes to userContent.css is pickup up by simply opening a new window For even better results, forget about external editors. 1. Press F12 to bring up the developer toolbar. 2. Click the Style Editor tab. 3. Above the file list on the left, click the upward-pointing arrow icon to import a stylesheet. Select your userContent.css file. 4. In the file list on the left, click "New style sheet #…". 5. In the pane on the right, make your changes. They'll take effect immediately. Also, the filename in the list should at that point change to userContent.css 6. To keep the changes, click "Save" below the filename on the left.

(In reply to Gingerbread Man from comment #33)

Opening a new tab or window does reflect changes in userContent.css now.

This is true only if (and because of) multiprocess Firefox is enabled (i. e. browser.tabs.remote.autostart is set to true), which have its own downsides, including userContent.css-related [1]. Singleprocess Firefox is still subject to this bug.

I believe, it is worth reopening.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1505868

(In reply to Dmitry Alexandrov from comment #38)

As far as I know, browser.tabs.remote.autostart = false isn't a supported configuration, so I'm not going to reopen this based on that.

(In reply to Gingerbread Man from comment #39)

As far as I know, browser.tabs.remote.autostart = false isn't a supported configuration, so I'm not going to reopen this based on that.

Well, is ‘dom.ipc.processCount’ a “supported configuration” then? When set to 1 the effect is the same.

(And sorry for off-topic, but does it mean, that single-process mode will be disabled entirely after a while? Where can I get more info on this?)

(In reply to Gingerbread Man from comment #37)

For even better results, forget about external editors.

  1. Press F12 to bring up the developer toolbar.
  2. Click the Style Editor tab.
  3. Above the file list on the left, click the upward-pointing arrow icon to
    import a stylesheet. Select your userContent.css file.
  4. In the file list on the left, click "New style sheet #…".
  5. In the pane on the right, make your changes. They'll take effect
    immediately. Also, the filename in the list should at that point change to
    userContent.css

Does this editor really support editing user stylesheets? That would be indeed very nice. But the steps you described result in applying userContent.css as an author stylesheet, which makes it absolutely unsuitable for previewing if your userstyle is in the least bit non-trivial.

(In reply to Dmitry Alexandrov from comment #40)

Well, is ‘dom.ipc.processCount’ a “supported configuration” then? When set to 1 the effect is the same.

Yes, that's the same as unchecking "Use recommended performance settings" in about:preferences#general then selecting a custom content process limit. With the limit set to 1, I can reproduce the issue with an external editor, while comment 37 still works. Since it works with the default settings, please file a new bug report.

(And sorry for off-topic, but does it mean, that single-process mode will be disabled entirely after a while? Where can I get more info on this?)

I don't know.

(In reply to Dmitry Alexandrov from comment #41)

Does this editor really support editing user stylesheets? That would be indeed very nice. But the steps you described result in applying userContent.css as an author stylesheet, which makes it absolutely unsuitable for previewing if your userstyle is in the least bit non-trivial.

I don't know what you mean by this without an example. To test, in one tab I appended userContent.css, added the rule * { background: red !important; } and saved. I then opened a different site in another tab, and it was applied there as well.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: