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

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 })
})();

You’ll be styling another element, that’s really all it is.

Normally Firefox applies various styling rules to the element with id urlbar-background - so it makes sense to also apply your custom style rules and overrides to it. If you apply your background-color or border or other rules to some other element such as #urlbar-input-container then the original styling of #urlbar-background still applies as well.

This would then cause issue like you would see in your first image, exactly like you guessed; the outline of #urlbar-background is seen behind the background-color of #urlbar-input-container because the two boxes don’t have exactly the same shape and thus you are not fully covering the urlbar-background.

If you aren’t doing anything else to urlbar then I’d recommend styling #urlbar-background instead of #urlbar-input-container - like this:

#urlbar-background {
  border: none !important;
  border-radius: 5px !important;
  background: light-dark(#ffffffff, #1b1e20ff) !important;
  outline: none !important;
}

You can change it like this with userContent.css:

@-moz-document url("about:newtab"), url("about:home"){
  :root{
    --newtab-primary-action-background: #f00 !important;
  }
}

That way you can specify a color for them, but setting the value to AccentColor may or may not resolve to the actual system accent color.

It’s all good my dude. There’s just so many small differences between just linux versions that I wouldn’t have been suprised if the style didn’t work in one of them.

Is your style up-to-date? This sort of sounds like issue #359 but that should have been fixed 2 months ago.

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.

I’m not sure about how the svg would work here (though it might work fine), but you can do that with just CSS as well:

@keyframes tab-gradient-anim{
  from{ background-position-x: 0% }
  to{ background-position-x: 200% }
}
.tab-content[selected]{
  background-image: linear-gradient(
        90deg,
        rgb(255, 0, 0) 0%,
        rgb(255, 154, 0) 12%,
        rgb(208, 222, 33) 24%,
        rgb(79, 220, 74) 35%,
        rgb(63, 218, 216) 44%,
        rgb(47, 201, 226) 50%,
        rgb(28, 127, 238) 60%,
        rgb(95, 21, 242) 70%,
        rgb(186, 12, 248) 80%,
        rgb(251, 7, 217) 90%,
        rgb(255, 0, 0) 100%
    );
  background-repeat: repeat-x;
  background-size: 200% 100%;
  animation: tab-gradient-anim 2s infinite linear;
  background-clip: text;
  color: transparent;
}

Yeah, sorry I missed the question about the popup. Yes, you can change it, but it’s via userContent.css not userChrome. Could look like this:

@-moz-document url("chrome://devtools/content/styleeditor/index.xhtml"){
  .menupopup-arrowscrollbox{
    background: #f00 !important;
  }
}

Note that this only changes the popup that appears in style editor because the other parts of the toolbox are separate documents. Also, it only works for “normal” devtools but not for browser toolbox - to affect that you need to first set up userChrome.css for the toolbox profile, it’s literally a separate firefox profile stored inside its target profile in a chrome_debugger_profile directory.

I think I looked into this some time in the past and it turned out that to do this, you need to use autoconfig scripting to inject a stylesheet as an agent style. Then, you can use style like this:

@namespace url('http://www.w3.org/2000/svg');

#box-model-elements{
  --highlighter-box-content-color: hsl(297, 71%, 53%);
}

I’m limiting that style to only apply to svg elements by namespace, because otherwise the style will apply to all websites as well. But nonetheless, this would also set this custom property to all svg elements in any svg that has has that particular id. Not a huge deal, the point is simply that you need to do something to limit the scope the you want to apply changes to.

Yeah, seems bunch of ids inside urlbar-input-container got replaced with classes in bug 1610530 - this was one affected style. Although this one was a bit broken even before that change I think.

I mean simply like this:

:root{ 
  backdrop-filter: brightness(99%);
}

Alternatively html selector would also work to refer to the document root element - about:newtab is a html document after all.

The same will also happen with filter, transform and a few other properties. The reason is that when these properties are applied then a new containing block is formed, and that will cause fixed and absolute positioned children to behave somewhat unexpectedly in they now “appear to reserve space” whereas normally they don’t. In this case the newtab options menu is fixed positioned, and thus if the body has backdrop-filter then the menu box causes the page to overflow.

There is an exception to that mentioned containing-block formation though; if you apply the property (such as backdrop-filter here) to the document root element then no extra containing block is generated. I suppose it should be pretty simple to just apply your rule to :root instead of body.

Right, that makes perfect sense. The property being a variable nor it having an important tag are not meaningful to explain what’s happening here.

What is important is simply what the address of the .css file is which sets the background-image property, because relative url resolves relative to that. The internal style sheet where this background-image property is set is chrome://activity-stream/content/css/activity-stream.css. So if the url it uses is ../newtab/wallpaper-dark.png (as by you setting the variable as such) then it will try to load an image from address chrome://activity-stream/content/newtab/wallpaper-dark.png which surely doesn’t exist.

But if you set background-image property from within userContent.css then the relative url resolves relative to that instead.

Sounds like what’s happening here is that the relative path you have given doesn’t resolve to what you think it does. See, the variable --newtab-wallpaper-dark is used by an internal style sheet, so when the url() actually gets resolved it will be relative to the internal style sheet address - not to the file path of userContent.css.

So, a workaround would be to give it an absolute file path or override the property where that variable is actually used.

Yeah, history is extremely valuable feature. I think I would rather get rid of bookmarks and maybe even tabs rather than history.

Fancy. Quite an artistic layout for sure.

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.