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.

At first glance that sounds like for some reason the tab selection is super slow occasionally. The selected attribute on .tabbrowser-tab happens very soon after you click the tab, but the other stuff happens and eventually the .tab-background gets its selected styling. Sounds like that would sometime take several frames during which the background-color is not covered by normal selected-tab styling.

You can try to replace [selected] there with [visuallyselected] which gets added a bit later, but if there’s some weird latency going on then that might still be too soon.

In horizontal tabs the tab is really removed only after its closing animation is done - in that case when its width reaches 0px. I have not looked what the closing transition is in vertical tabs - but it stands to reason that it might be its height. If that is the case (which again is just a guess) then you should make sure that you aren’t setting min-/max-/height for tabs anywhere that then would prevent the tab from being getting to 0px height.

I’m not sure if we’re talking about the same thing, but the first thing I noticed from that video is that it seems as if tabs aren’t closing properly. Same kind of deal happens with horizontal tabs if you unconditionally force min-width or max-width for tabs.

That being said, I wouldn’t put too much effort into supporting vertical tabs yet because it’s constantly changing still.

Also, Servo was originally more or less a testbed for new rendering pathway (webrender) which, when ready, was then integrated into Firefox.

The main window has a [inDOMFullscreen] attribute when a video or other website element is being shown in fullscreen mode. So use that instead of [sizemode="fullscreen"]

True, and I agree - for this feature to be effective the site-specific rules need to be maintained properly.

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.

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.

Something like this should work:

#navigator-toolbox::after{
  height: 1px;
  background-image: linear-gradient(to right, blue, yellow, cyan, magenta, red);
  order: 1000;
  content: "";
  display: flex !important;
}

It is, but like it says you need to get window_control_placeholder_support.css for window controls to show properly at the top.

What exactly did you do to do what you did?

Reader mode can show images as well though. I mean, it isn’t always successful in doing so - probably because there’s about a million different ways a random website could show an image - but reader mode can show images that it thinks are part of the actual content.

I’m not seeing any such issue with Nightly on my Fedora system.

Indeed. Also, the auto-open PiP is super nice feature I’ve been using a lot.

Right, though “bug” here really means an intentional change, not so much something that is broken.

I suspect that the cause is from bug 1897477 - whereas previously your script overrode the original command ctrl+f event callback, with this change both callbacks happen. So when findbar is already shown, your script will hide it, but then the original Firefox function shows it again.

You can probably change the last part to be like this instead (I don’t really get what the middle part is supposed to do, but meh):

(function() {
  document.getElementById("cmd_find").addEventListener("command",(ev) => {
    ucjsToggleFindBar();
    ev.stopPropagation();
  }, { capture: true })
})();

I don’t think Firefox Color can do that. At best you could test and set colors using Color, and then export the settings for both as a theme .zip or .xpi files, and then combine the two to a single manifest.json file. Inside the manifest, a "theme" key would be color properties for “normal” theme and "dark_theme" would be for dark-theme. After that you would submit the theme package to get it signed after which it can be installed as a real theme.

You can modify prefs at runtime and have them persist - except those prefs that are also declared in user.js. The problem arises when folks apply whole list of prefs via user.js from one repository or another, which could be hundreds, without acknowledging what prefs they set and without checking what those prefs do. If they then have some reason to change any one of those prefs - their change won’t persist if that particular pref is in user.js

A thing you could do is to just start Firefox once with a user.js file, and then remove that file. On that single startup Firefox sets prefs according to user.js, and all those changes persist to prefs.js when Firefox is shutdown. You are then able to also persist changes to all prefs because by removing user.js Firefox won’t try to override the your session saved prefs with user.js at startup.

Yes. Firefox doesn’t create user.js file itself - if you want one then you need to create it yourself either manually or with some tool. Also, I’ve seen some “security” software create user.js file without notifying the user about it…