https://hg.mozilla.org/mozilla-central/rev/f61a27b00e05 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140730030201
Alice, is this userContent.css problem a regression from the changeset you link in comment 0? Is this really an IPC bug?
(In reply to Chris Peterson (:cpeterson) from comment #1) > Alice, is this userContent.css problem a regression from the changeset you > link in comment 0? Is this really an IPC bug? Sorry, I am not sure which component is best. At least, the problem exists since Firefox25's e10s.
Hi. As a Nightly user, I would like to help test e10s, but I am also a heavy user of userContent.css (rather than, say, Stylish, because it's baked into Firefox and dead simple to use), so I always end up reverting `browser.tabs.remote.autostart` each time e10s is pushed to me. Also, userContent.css / userChrome.css look very much like the kind of [advanced + little-discoverable] feature that Mozilla might want to sever to reduce the configurable surface and encourage usage of an extension. This said (and sorry for the "ME TOO, and by the way I have a question" digression), is there a possibility this bug ends up WONTFIXed, or am I dreaming this up and it's unfixed simply because nobody had the time to look at it yet?
browser.tabs.remote.autostart.1 was set to true in today's Nightly 38.0a1 (2015-01-14), and I re-flipped it to false to have my userContent.css working. Is the feature going to be supported at all in e10s?
That's the plan, it's just a much lower priority than all of the other work happening.
The Nightly and Aurora now Directory "chrome" important for many people! Me, forced to disable multi-process !
Hello With the update of Firefox Developer Edition 16-07-2015 42.0a2, chrome folder that contains userContent.css no longer works ... To solve this regression, we must unfortunately disable multi-process mode for userContent.css is again considered.
If somebody wants to debug this, a good place to start would be nsLayoutStylesheetCache::InitFromProfile (in the content process). My guess would be that something it does doesn't work in the content process. https://hg.mozilla.org/mozilla-central/file/0876695d1abd/layout/style/nsLayoutStylesheetCache.cpp#l397
I think what's happening is that we don't know the location of the profile directory in the content process. That's to avoid accessing the file system, which will be forbidden once we have a full sandbox. I'm guessing we're returning here: https://hg.mozilla.org/mozilla-central/file/0876695d1abd/layout/style/nsLayoutStylesheetCache.cpp#l414 I think we need to design something here that will send down the style data from the parent. Maybe we could load the style sheet text in the parent and send it down to each child upon startup. Does that seem reasonable David?
(In reply to Bill McCloskey (:billm) from comment #9) > I think what's happening is that we don't know the location of the profile > directory in the content process. That's to avoid accessing the file system, > which will be forbidden once we have a full sandbox. I'm guessing we're > returning here: > https://hg.mozilla.org/mozilla-central/file/0876695d1abd/layout/style/nsLayoutStylesheetCache.cpp#l414 Hi, I'm working on this bug (observers: no promises made! I'm not an employee and this is my first tentative at mozilla dev; just giving it a try, maybe I'll succeed and maybe not). I didn't validate this and thought the child didn't have to pass through this code. With Bill's suggestion and now understanding a bit more about e10s, I'm going to validate this with logging. Logging is my only option for this, right? Reading the e10s/debugging wiki page [1] and mconley's blog post [2], I don't see a way to tell gdb to "attach to any child at nsLayoutStylesheetCache.cpp:l414" in order to catch such early initialization work. Wrong? > I think we need to design something here that will send down the style data > from the parent. Maybe we could load the style sheet text in the parent and > send it down to each child upon startup. Does that seem reasonable David? Also, how should non-e10s windows be covered? a. Branch to keep using to the current code if in a non-e10s window. b. Do the kind of message-passing you describe in non-e10s windows too. [1] https://wiki.mozilla.org/Electrolysis/Debugging [2] http://mikeconley.ca/blog/2014/04/25/electrolysis-debugging-child-processes-of-content-for-make-benefit-glorious-browser-of-firefox/
Bill is probably a better person to answer comment 10 than I am, although I could try...
(In reply to Bill McCloskey (:billm) from comment #9) > I think we need to design something here that will send down the style data > from the parent. Maybe we could load the style sheet text in the parent and > send it down to each child upon startup. Does that seem reasonable David? I guess it does... although maybe we could instead piggy-back on the way we load the UA style sheets, which is with resource:// URLs. Then again, maybe it's problematic that the resource: URLs for the UA sheets are (I think) in JARs, and these wouldn't be.
We actually have some existing code to send style sheet loads down to the child process: http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#2570 http://mxr.mozilla.org/mozilla-central/source/layout/base/nsStyleSheetService.cpp#160 David, is there a way we could use this code for userContent.css. I'm not familiar with all the loading mechanisms at play here.
I don't think that helps with this (at least in the long term in terms of security models as you describe in comment 9), since that just sends a URI down to the content process, which it then invokes network code on, which goes back to the parent process to do the load. Whereas here the content process already knows it needs to load a particular URI, it just needs a way to tell the parent process to load that URI in a way that the parent process can tell is safe. I suppose that we could have the parent process get the profile directory, but it sounds like we don't want the child process to know where the profile directory is or have access to everything in it, so it seems better to have a special URI just for these two style sheets (userContent.css and userChrome.css).
Maybe crazy, but could we just use a data: URL? It would be a lot easier. I doubt users are using gigantic style sheets here.
(In reply to Bill McCloskey (:billm) from comment #15) > Maybe crazy, but could we just use a data: URL? It would be a lot easier. I > doubt users are using gigantic style sheets here. Hi. No idea how representative I am of the users of this feature, just providing one data point: after a few years of usage, my userContent.css has rules for ~30 web sites, and is 10kB.
Hi. Chiming in to add two things: 1. (Addressed to other users of the feature) Extension "dotjs" [1] is a 100%-"compatible" alternative to userContent.css. Just symlink your userContent.css to ~/.css/default.css and you're done. There are other ways to use the extension (e.g. one file per domain), but since it's fine with the `@-moz-document...` rules our userContent.css uses and supports this `default.css` special case that is loaded on all domains, it's feature-identical (and more) to userContent.css . One regression is that the css isn't instantly applied, on my machine there is a maybe ~500ms on load without the custom style, then it's applied. 2. (Addressed to potential developers of this bug) Actually, the extension is *better* than userContent.css, because changes to the custom css file don't require a Firefox restart, only a page reload. If work is done to restore the feature in e10s, it would be nice to not require a restart too. Or better, it would be *super* nice to monitor the css file and apply changes instantly (like Chrome's `User Stylesheet.css` used to do before the feature was axed) [1] https://github.com/rlr/dotjs-addon , https://addons.mozilla.org/en-US/firefox/addon/dotjs/
https://addons.mozilla.org/en-US/firefox/addon/dotjs/ is not signed Even if so it never be look truster then core userContens.css Firefox feature...
*** Bug 1234188 has been marked as a duplicate of this bug. ***
userChrome.css and userContent.css not work also on Firefox Aurora Developer Edition 46.0a2. Problem with add-on uc https://addons.mozilla.org/pl/firefox/addon/uc/
-> tracy for a qa report.
I put little style change in /Users/tracy/mozilla-central/obj-x86_64-apple-darwin13.3.0/dist/bin/browser/defaults/profile/chrome/useContent.css /* Put a thin black border around all dropdown forms like NS4.x */ :-moz-dropdown-list { border: 5px solid black !important; border-top-style: solid !important; } I am not sure why/how, but this change is affecting all of my Firefox/Nightly installations. Anyway, the css works in non-e10s but fails to draw a small black border around form drop downs in e10s mode. I tested with latest Nightly 47.0a1, 20160203030249 on Mac 10.9.5. I can't figure out how to replicate on Windows or Linux, short of building Nightly, which I am not setup to do on those platforms. Also note: I tried using Stylish and one of its basic/popular style changes and it does work in e10s.
Kev: I think we should drop support for userContent.css and suggest that people replace it with greasemonkey-like addons (this can be done using the addon SDK as well as webextensions). Can you confirm that decision and if so we'll morph this bug into removing userContent.css support in general in favor of an addon-based approach.
userchrome.css and usercontent.css are have more features. Greasemonkey is for web/javascript, but Stylish is for change web style and Firefox theme/style
The support for userContent.css (and userChrome.css) should not be dropped except we want the next shitstorm because of the removal of another customization option. The advantage of these files is that you _don't_ need an add-on, it's a built-in customization feature. There are already a lot of users upset because they need more and more add-ons every year and because Mozilla removes a lot of feature for power users. Please consider that the power users are the users who recommend Firefox or destroy the image of Mozilla in the comment sections of every Firefox article in the web. Please don't underestimate the impact of these users. Mozilla should have learned from the past, there were already a few PR desasters. ;-)
for **** sake
>removing userContent.css support in general in favor of an addon-based approach. Stupid, stupid, stupid.
This is needed feature for many users. Addon is not option(unless firefox make it built in). I voted for fix, not for removing.
I’ve been using Firefox since it was Phoenix. Firefox has been with me, from one computer to another. And with every new Firefox release things turned more and more into a direction Firefox power users did not like at all. Here is the thing guys: When a project changes so much that it ceases to be recognizable, its name should be changed. To keep the Firefox name now is actually dishonest. When a project decides to chase the marketshare captured by other browsers, it ceases to be unique and ceases to be relevant. If people want Chrome, they will use Chrome. People who have been using Firefox for it's whole run will switch to a fork or numerous other browser projects, some of which are based on Gecko, some not: these projects respect the user, the human being that needs consistency and reliability, power and freedom. The fast releases have been a mixed bag, Australis was implemented because Mozilla wanted so much the users who switched to Chrome back, newer releases have been bad for extension developers, and in that way bad for users. Then there was the Eich debacle and Gamergate. Together, those signaled a changing of mindset. Why stay with someone who doesn’t want me? Why make myself miserable trying to make my partner faithful when it has decided to be unfaithful? Why does this always have to happen? But thankfully, free software means that in one way or another, the phoenix can live on. Firefox is dead. Long live the phoenix, whatever it turns out to be. Whatever takes Firefox place will be true to the original: user-focused, freedom-defending, corporate-shunning, and not addicted to billion-dollar deals.
This is the actual problem. And it is nice to see something like that coming from a wholehearted Mozilla supporter who is under normal situations against power users or features in the browsers core in general. Thumps up for this! In the end Mozilla could have kept our loyality from us power users. Since Australis we got over and over humiliated and fooled by Mozilla, while single users got everything they wanted, while social networking users got all what they wanted. I also have to agree with everythiing vladdrakul wrote. How about trying to keep a feature for once Mozilla instead of outsorcing every complex feature to add-on developers? As long as you treat us like dirt, we too will keep you like dirt Mozilla. Sören was right, you guys have already created tons of bad publicity over and over the whole web, and many ocne proud Mozilla Firefox power users are bashing you in the meantime all over the web, and you have earned that guys, for ignoring us over and over again. How about if you take a look at the guys over at Vivaldi or Brave? They are interested what the user wants, they are interested in implementing what the user wants, they openly declare that features and customization and being special is of more value then being like another browser. Every of these browser projects is more open and more fair as compared to you guys. If you take away also that toy here for whatever for reasons, you can indeed as Soren already wrote some shitstorm upcoming. And it is all your fault. Same for removal of XUL and full themes without actually being interested to create the same as powerful methods to customize the browser in Servo. Not treatening you, but keep in mind, the more you anger power users who once advocated you all over the web, the more these guys are turning into rabid Mozilla haters, take their converted users with them to other projects, you lose market share and importance. Is this really what you want Mozilla? I can't really believe that.
Replace userContent.css by Greasemonkey is a big mistake !! Stopped to switch users to add-ons !!! Greasemonkey may bring bugs if compatibility issues with updates to Firefox !! UserContent.css use is less risky. (Holds it reminds me of my message out there on userChrome.css !!: https://bugzilla.mozilla.org/show_bug.cgi?id=995095#c10 ... Grrrrr) For dévelloppeurs, avoid miscommunication ... Users growl you more and more, on many fronts! Mozilla risks losing big and hit the wall ...
(In reply to Benjamin Smedberg [:bsmedberg] from comment #23) > Kev: I think we should drop support for userContent.css and suggest that > people replace it with greasemonkey-like addons (this can be done using the > addon SDK as well as webextensions). Can you confirm that decision and if so > we'll morph this bug into removing userContent.css support in general in > favor of an addon-based approach. I have a better suggestion, since you against every customization, move to google chrome!
I wander if support for 'user.js' also dropped? > SpeciesX: I have a better suggestion, since you against every customization, move to google chrome! I use Chromium for MOOC exclusively (https://en.wikipedia.org/wiki/Massive_open_online_course) because on Debian Linux Iceweasel have many issues with WEBM/H.264/Streaming and doesn't work at all in the past. edX and Coursera require HTML5 + Video. I stay with Firefox because I know a little of XUL/XPCOM and expect to get benefits from knowledge. I like to try work in Conkeror (http://conkeror.org/) - bloat free version of Firefox. Also Chrome have no feature: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector Even when Firefox team broke :visited styling with privacy concern without no-opt it is in every day usage. Splitting single Firefox instance into several is good changes. With 1500 open and 300 active tabs - Firefox work fine with multi-process enabled on. Especially improved Firefox start time. That means that instead of fighting with memory management Firefox team decide just drop processes like that do Chrome at the starting design.
For those who wonder how to disable multiprocessing: https://bugzilla.mozilla.org/show_bug.cgi?id=1234188 > Gingerbread Man: It will only work if you've unchecked “Enable multi-process” under Options / Preferences → General and restarted when prompted. I can't find corresponding "about:config" option.
Thanks! Good job hiding all these criticizing comments, we don't want to hear any different opinions in here.
Google doesn't hide any comments at code.google.com/p/chromium btw
(In reply to Benjamin Smedberg [:bsmedberg] from comment #23) > Kev: I think we should drop support for userContent.css and suggest that > people replace it with greasemonkey-like addons (this can be done using the > addon SDK as well as webextensions). Can you confirm that decision and if so > we'll morph this bug into removing userContent.css support in general in > favor of an addon-based approach. Maybe you could add "user script addons" instead of a third party addon for user scripts. Something that mostly just encapsulates a script and some metadata, that can be easily edited with a built in editor. (Which already exists: Scratchpad)
(In reply to Kamiru_ from comment #35) > Thanks! Good job hiding all these criticizing comments, we don't want to > hear any different opinions in here. Bugzilla is the wrong venue for those comments. They should be taken one of the firefox-dev or dev.platform mailing lists (https://www.mozilla.org/en-US/about/forums/#dev-platform and https://www.mozilla.org/en-US/about/forums/#firefox-dev). This bug should be focused on the technical challenges associated with the solution decided upon.
(In reply to Josh Matthews [:jdm] from comment #38) > Bugzilla is the wrong venue for those comments. > This bug should be focused on the technical challenges associated with the solution decided upon. So Mr. Smedberg shouldn't have started it by suggesting pseudo-solution. Removing features is not an option. You devs should be focused on resolving problems, not creating more of them.
I tested add-on UC and userchrome.css work great uc version 20160205 https://addons.mozilla.org/pl/firefox/addon/uc/ More about this addon: Allows you to run arbitrary custom scripts in specified chrome windows. In short, userChromeJS + subscriptoverlayloader.js. usercontent.css is for only web. Stylish is more powerful
I would like to say that while I am not currently using e10s, I do rely on userContent.css for in my opinion a rather critical part of my user experience that should not need an extension. I use a dark GTK theme, and one of the first things I noticed were the issues noted here: https://wiki.archlinux.org/index.php/firefox#Unreadable_input_fields_with_dark_GTK.2B_themes. While I do use Stylish for other things, I think that I should not need a browser extension/add-on in order to have a non-broken user experience when using a dark GTK theme.
I disagree with this for many reasons. Just because you don't use it, that doesn't mean Mozilla should hurt users who are. I personally don't use it a lot, but I need it. Stylish may be an addon that does this, but some people don't like using addons.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #23) > Kev: I think we should drop support for userContent.css and suggest that > people replace it with greasemonkey-like addons (this can be done using the > addon SDK as well as webextensions). Can you confirm that decision and if so > we'll morph this bug into removing userContent.css support in general in > favor of an addon-based approach. I disagree with this for many reasons. Just because you don't use it, that doesn't mean Mozilla should hurt users who are. I personally don't use it a lot, but I need it. Stylish may be an addon that does this, but some people don't like using addons.
I don't know this is related to Bug 1221724 - Remove xulrunner from mozilla-central, userContent.css seems to work in the latest central with e10s. Can anyone confirm?
> I don't know this is related to Bug 1221724 - Remove xulrunner from > mozilla-central, userContent.css seems to work in the latest central with > e10s. userContent.css still does not work in the latest central. I've rushed for a conclusion. I'm sorry about my fault.
Jeff, any opinion here? Tjis bug is currently caught in triage limbo waiting on feedback from Kev.
(In reply to Jim Mathies [:jimm] from comment #46) > Jeff, any opinion here? Tjis bug is currently caught in triage limbo waiting > on feedback from Kev. I think we should fix this instead of waiting for an add-ons plan that will require migration. This is a regression and there seems to be some ideas in the previous comments on how to fix it.
or
