Yeah, I just figured the safest option would be to only set the actual document root element transparent - in practice I think it's possibly more likely that the `` element has background set by the page - although the page might as well set both. So yes, it depends on the website.
I think the answer depends on which elements exactly you want to make transparent. The page is a layered structure. The html root element is behind them all. Then body element is on top of that, the rest of the elements on top of body, etc.
So if you intend to have transparency all the way down, then you need to make sure that all the elements in that stack are transparent. If any single item in a stack has an opaque background then the transparency effect stops at that.
As an example, if you set background:transparent to just body but not the document root element, then body will indeed be transparent, but it does not matter because the root will still be opaque. Likewise, if root is made transparent, but there is any opaque layer on top of that, then only the parts of the root element that are not covered by that opaque layer will show up as transparent. If you have a glass table and put a sheet of paper on top of it, then you don't see through the part covered by the paper even though the table itself is transparent.
Yeah, !important doesn't affect inheritance in any way. It only means that this particular rule is to be used if there are multiple rules that would set that particular property for the element in question (unless there's some other more specific rule with !important tag as well). MDN lists property inheritance in the formal definition section. You can totally make background-color inherited though - like *{ background-color: inherit } (and then set the property to something else on the root element from which you would want to inherit from) but it would then either not apply if website set it to anything else for an element or override any other set value if you used !important tag.
One other thing worth noting is that I would not recommend the rules mentioned for userChrome.css to be used as is - at least on window they completely break Firefox startup - it fails to display any window if you do that. Instead you should add a [sessionrestored] selector to wait a bit before those rules are applied to main-window:
#main-window[sessionrestored], #tabbrowser-tabpanels{ background: transparent !important; }
Right, background-color is not an inherited property (compared to for example color (color of text) which is). But even if it were, inheritance is not "enforced" so if website css sets a backround-color specifically for that element then the inherited value would be lost anyway.
But the way you now describe it doesn't seem possible. There is not syntax to apply style rule to "just the innermost element". I think the closest would be to have everything else have fully transparent background, but the html root element have only partial transparency:
*{
background: transparent !important;
}
html:root{
background: #00000080 !important;
}
However, you will still face a problem; many websites draw graphics or images as a background-image so if you use the background shorthand property then those graphics will be effectively removed. On the other hand, if you instead set just background-color then parts might get opaque again because a website could be drawing even opaque backgrounds as background-image instead of background-color.
Unfortunately by sending DNT you are merely suggesting to the server that you wish to not be tracked. There's no requirement for the server to actually care about you at all.
Now, if DNT were actually legally binding though - that would indeed be very cool.
If a website has a compatible PWA manifest the there will be an item labelled "install" in the three-dot menu of Firefox in place of usual "add to homescreen" item.
Edit: There's a few other requirements as well for the website to be considered installable as PWA, such as it must have a registered service worker so it can work offline. But regardless, if the website provides all the requirements then it can just be installed straight from the menu.
None.
I don't think it's a good idea to take some huge collection of prefs and just apply them blindly.
Instead, make the changes that you actually want to do, so that you actually know what changes you are causing. If you want to put those into your user.js file then feel free, but in my opinion it's just better to change them in about:config directly - that is, unless you need to apply the exact same set of changes to multiple profiles.
Right, but then you shouldn't be shocked to find out that a feature was removed because nobody seemed to be using it.
My first guess would be that this is caused by the website implementing its own navigation/history behavior using History API. That can easily mess things up, or at least not behave like you might want.
Also, Servo was originally more or less a testbed for new rendering pathway (webrender) which, when ready, was then integrated into Firefox.
Well the feature development is certainly progressing - here is the tracking bug for it.
You can nowadays just test it in normal nightly without special build - it's extremely incomplete, but you can test it if you wish. It's tied to revorked sidebar which you need to enable in about:config.
Doesn't really sound like a company that I would want to do any business with then.
Also, with mv3 extensions, the extensions that are not actively doing some work are not really "running" in the first place but are just waiting for some event to happen that they have previously told Firefox to inform them about, but there isn't any persistent execution context that is constantly running.
I believe one reason why extension support was not-fully enabled earlier was because mv2 extensions required persistent background context for each extension and that could cause issues if Android just decided to kill that process. But with mv3 the extensions are required to be able to be suspended and then woken up on demand.
IIRC the old tab groups feature was eventually removed because telemetry showed that only very few people used it...
I think this really comes to what exactly you want to separate. You say "I often need to use two different profiles". Okay, why do you need to use separate profiles though? Maybe separate profiles are not a great solution in the first place for your purpose?
Firefox profiles are amazing because you can be sure that no data is shared between the two profiles (unless you sync them of course) - for whatever reason one might want that. But if you just need some session separation then containers would be a much better fit.
In that case the issue is likely that files on disk are being modified by whatever mechanism your IT uses to push updates to devices. If the program files are modified while Firefox is running then you will unavoidably get this prompt.
I suppose the best you can do is to ask your IT folks to not update programs that are currently running.
That feature removes parameters that are known to be used for tracking. It does not remove all query parameters willy-nilly. For example on youtube it should remove si, feature and kw parameters as well as a set of parameters on a list that applies to all websites. However, pp parameter is not in that to-be-removed list.
As an example v parameter is for video id on youtube, it would be kinda silly if that was removed, so the feature kinda has to do some site specific action.
I guess this style might fit the bill
I mean, first you need to set up using custom style sheets - some guidance here, but after you've set that up you can try the style I mentioned.
Yeah, history is extremely valuable feature. I think I would rather get rid of bookmarks and maybe even tabs rather than history.
Felix Mikolasch, data protection lawyer at noyb: “Mozilla has just bought into the narrative that the advertising industry has a right to track users by turning Firefox into an ad measurement tool. While Mozilla may have had good intentions, it is very unlikely that 'privacy preserving attribution' will replace cookies and other tracking tools. It is just a new, additional means of tracking users.”
Sigh... I cannot for the life of me figure how anyone could think that enabling PPA (even by default) means that advertising industry has somehow right to track folks. Like dude, the entire point of PPA is that advertisers could then get to know if/when their adverts are working without tracking people.
The argument that "It is just a new, additional means of tracking users" also doesn't really make sense - even if we assume that this is new means of tracking. I mean, sure it technically is new addition, but it's like infinity+1 is still infinity - it doesn't make a difference. The magnitude of this one datapoint is about the same as addition of any new web api (I mean there are lots that shouldn't exist - looking at you chromium.. but that's besides the point).
File a complaint over use of third-party cookies and actual tracking if you want to be useful - this complaint just makes you look like an idiot.
There isn't anything to specifically update the favicon of a tab. But you can do the exact same thing websites can update their favicon with; run a content script on the web page that modifies the favicon. Firefox will then show whatever the new icon image is in the tab bar.
I don't have a better example but the content script of an extension I wrote updates the favicon during media playback in a tab. As an overview it creates a canvas of the original favicon, creates a new link element as the "new favicon", updates that canvas during playback, and then sets the created link element href attribute to the data uri created from the canvas.
Right, and that's fine. The one good thing about these "collections" is when they describe what the pref does (I mean, so does official source typically). But that matters only as long as the audience actually reads those descriptions. But then if you just pick the ones you actually care about (which you should totally do) it becomes irrelevant from which "collection" you found about it from.
Not at all the same thing. For one, you can open a history entry and then navigate back from that to the page you came from to that page - which there may be several. Tabs preserve per-tab history which makes it superior in many ways to both history and bookmarks.
This should be pretty simple to do, although what exactly do you consider a "duplicate"? Does it count as duplicate if the bookmarks have the same name, or same url, or does both name and url need to be equal?
Edit: So the extension could work like this - it's awaiting review, but the eventual AMO page would be here
All I'm saying is that it leaving some query parameters unremoved is not indicative of the feature not working. If you want to add more query parameters to the removed list then feel free to open a bug about it.
Okay, since it doesn't like it's your main computer or anything, you might be interested to try taskbar profile grouping. Go to about:config and while there create a new boolean pref named taskbar.grouping.useprofile and set it to true. Doing that the two profiles should have their own group in taskbar. It's a very crude feature though, since for example the right-click jump list items are not separate and you can't set different icons for them (unless you do that via Windows somehow), but it sort of works.
Indeed, but what I don't get is why on earth do people spew this damn crap about manifest v3 as a whole, when the actual issue is just the removal of "webRequestBlocking" feature that Google is about to bring along with their implementation of mv3. Why the hell aren't folks mad about the actual issue but instead just want to be mad about the whole bloody thing, which actually also does bring some very real privacy improvements among other nice things.
Would be pretty idiotic to not close it, otherwise opening a bookmark would always require a second click to close the popup.
Anyways, you can go to about:config and set browser.bookmarks.openInTabClosesMenu to false - afterwards you can hold Ctrl (or just click the middle mouse button) while clicking a bookmark from such popup and the popup should stay open.
This isn't true anymore. Any extensions that are explictly marked as Android compatible (by the author) should now be installable from AMO. I'm pretty sure that the extension needs to use manifest v3 to be able to be Android compatible, but as long as that is true and the author has set the Android compatibility flag, you should be able to add it normally.
Installing from AMO seems to work fine for me - although I'm using Nightly variant, which certainly could behave differently. However, Firefox 120 is supposed to work the same I believe.
Notepad++ works great for taking notes. Besides, it's open 24/7 anyway so dedicating a tab or two (or dozen lol) feels pretty natural.
I only use Joplin if I have some "very structured" notes about some topic, and while that is also open 24/7 np++ is always my go-to because "it just works" without having to care at all about formatting nor anything fancy.
You just have the link texts in a text editor one at each line, then select all and drag the selection to tabs toolbar.
But yeah, it does become an issue if you try it with thousands of tabs... It should work, but probably chokes quite a bit.
I don't know if the syncing part will work for unsigned extensions, but you need to use the same storage area on both endpoints. So if you set kitten key to sync area (browser.storage.sync) - then you need to also read it from the sync area, but in your example you are reading from local area which is for local not-to-be-synced data only.
That ain't normal. You can certainly customize Firefox to behave that way with custom userChrome.css file, but you would have to do that on purpose.
I suppose it's also possible that if Firefox is installed via your package manager then they might do some customization to it. I've seen some linux distros package these sorts of custom Firefox builds that apply various changes to official Mozilla builds.
I have no clue about hacking macOS
Yeah, that indeed sounds like a bug.
Take this with a grain of salt, but I believe I've read that standard backdrop-filter won't work here and this would instead require OS compositor level mechanism because menupopup and panels are technically separate windows (or window-like widgets) from OS perspective.
Fair. For something like that containers don't work, and indeed profiles are probably the way to go. I sure wouldn't mind if about:profiles had a button to create new icon for that specific profile which then would also be in its own taskbar group, but I doubt I would want it as default for new profiles.
At any rate, having multiple profiles per same install on same Windows user poses some issues. Like what profile are links in other applications supposed to open in?
I mean, do whatever works for you, but that sounds kinda unnecessary when you can just use an already existing feature - tabs.
True, and I agree - for this feature to be effective the site-specific rules need to be maintained properly.
I don't think I understand exactly what parts you want to make transparent, but this does work:
browser.tabs.allow_transparent_browsertotrue#main-window, #tabbrowser-tabpanels{ background: transparent !important; }html:root{ background-color: transparent !important; }The above would make window background, and the are behind web-content transparent as well as background of html documents - otherwise the background of browser area wouldn't show up anyway. Toolbars that have their own specified colors would still be colored - which might be opaque or not depending what theme you have selected.