MrOtherGuy

joined 2 years ago
[–] MrOtherGuy@lemmy.world 9 points 3 weeks ago (1 children)

Go to about:config and set the pref browser.ml.chat.hideLocalhost to false Afterwards you can select localhost as the provider in Settings > Firefox Labs

[–] MrOtherGuy@lemmy.world 1 points 1 month ago

F12 opens web developer tools - the console there runs scripts in the website context - you cannot use that to access browser internals like PlacesUtils.

You need to run your script via browser console, I can't remember a hotkey for it, but you can find it from menu > more tools... > browser console

Also, I'm not sure but there's a chance that browser console is "read-only" in release firefox - meaning you might not be able to run anything from it. If that is the case, then open normal web developer tools (F12) and go to its settings, there's some checkbox there to enable "browser chrome debugging" or something like that. After checking that (and reopening browser console) you can run your function from browser console.

[–] MrOtherGuy@lemmy.world 1 points 1 month ago (2 children)

How exactly are you trying to run your javascript? Website javascript certainly won't be allowed to create bookmarks. If you run the function on browser side however, then it should work fine - but then I don't understand why it's wrapped into javascript url.

If it's a javascript: url because you tried to run this as bookmark itself (ie. clicking this special bookmark creates another bookmark folder and a bookmark inside it) then that's not going to work because that's pretty much just user provided code running in website context.

[–] MrOtherGuy@lemmy.world 1 points 2 months ago (1 children)

That is not browser toolbox - just normal devtools. Browser toolbox is separate tool which is used to inspect the browser window itself rather than web content. It's essentially a separate Firefox instance with it's own profile.

[–] MrOtherGuy@lemmy.world 2 points 2 months ago

That is not possible. Browser toolbox runs in a completely separate Firefox instance in a separate profile so there's no way you could display it inside the "main" browser window.

[–] MrOtherGuy@lemmy.world 2 points 2 months ago

I don't think there a way to open the library to history section via address. Library window history and bookmarks section are the same document, and the buttons that open open library window to history view do it by opening the window with extra window arguments - which you cannot do by simply changing the url.

A possible other option to show history would be to open Firefox view to history section. about:firefoxview#history

[–] MrOtherGuy@lemmy.world 1 points 2 months ago

There's also another thing that I don't think is mentioned yet. The options available in Settings are supported features. If the feature is only available via about:config then there's a good chance that it is not supported or tested configuration. It might work or it might not, at least not in all scenarios

[–] MrOtherGuy@lemmy.world 4 points 2 months ago

A subset of "advanced" users might have turned telemetry off so it certainly is skewed somewhat, but I don't think there a good reason for me to believe that the subset is necessarily that large.

[–] MrOtherGuy@lemmy.world 11 points 2 months ago

I'm guessing that the reason (and a good one at that) is that simply having an option to connect to a local chatbot leads to just confused users because they also need the actual chatbot running on their system. If you can set up that, then you can certainly toggle a simple switch in about:config to show the option.

[–] MrOtherGuy@lemmy.world 4 points 3 months ago

You can hide them with userContent.css - most of the devtools window stuff is styled via userContent.css not userChrome.css.

But there's a catch.

Browser toolbox is essentially a separate instance of Firefox, running in separate profile so your "normal" user css files don't apply to it. Thus, you need to first enable the toolbox profile to load it's own user css files and create them just like you do normally (toggle toolkit.legacyUserProfileCustomizations.stylesheets, create files in chrome/ folder etc.). The toolbox profile is stored inside the regular profile - in a directory chrome_debugger_profile.

To get to about:config of the toolbox profile you need to first open a new main-window for it - one way that works is to click the meatball menu at the top-right of the toolbox window, and select "Documentation..." - that will launch a new window using using the toolbox profile and then you can just open about:config and proceed as usual. Or you can just modify prefs.js of the toolbox profile directly while the toolbox is not running.

Anyway, after you have set up the toolbox window to load user css files, then just slap this to its userContent.css and restart the toolbox:

header.chrome-debug-toolbar{
  display: none !important;
}
[–] MrOtherGuy@lemmy.world 1 points 3 months ago* (last edited 3 months ago)

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 Windows 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; }
[–] MrOtherGuy@lemmy.world 1 points 3 months ago (2 children)

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.

 

Hi! Just FYI folks, the plan going forward would be to build this community on Fedia instead: Right here https://fedia.io/m/FirefoxCSS

Thanks to federation, you can also participate in the community through lemmy if you want - though some features such as microblog or sidebar info won't be accessible via lemmy - for now at least. The link to access the community via lemmy world would be https://lemmy.world/c/FirefoxCSS@fedia.io

See ya there!

1
submitted 2 years ago* (last edited 2 years ago) by MrOtherGuy@lemmy.world to c/firefoxcss@lemmy.world
 

Perhaps not fitting exactly for this community because it's about a website, but hey c'mon its customizing :) Apply via userContent.css or Stylus or something.

Only tested with "darkly-red" style that you can select from your user settings.

 

Let's have this post here also...

As a part of the front-end technical modernization the old xul box model is being replaced with modern flexbox all around the UI. Relevant bug 1820534

Previously, just about everything used display: -moz-box but in Firefox 113 the default display model was changed to modern display: flex instead.

What this means first-hand is that all legacy box model -related properties will not do anything anymore so things like -moz-box-ordinal-group, -moz-box-orient, -moz-box-direction, -moz-box-align, -moz-box-pack or -moz-box-flex won't have any effect.

The suggested way to deal with this is to just update your styles to use equivalent flexbox properties. Additionally, the old display: -moz-box is treated as invalid property value

Some examples of conversions:

  • display: -moz-box -> display: flex
  • -moz-box-ordinal-group: 0 -> order: -1
  • -moz-box-orient: vertical -> flex-direction: column
  • -moz-box-direction: reverse -> flex-direction: row-reverse
  • -moz-box-align: center -> align-content: center or align-items: center depending on what you are doing.
  • -moz-box-pack: start -> justify-content: flex-start or justify-items: flex-start
  • -moz-box-flex: 10 -> flex-grow: 10

Notes about order vs. -moz-box-ordinal-group: order supports negative values, whereas ordinal-group does not. Default value of order is 0 but default of ordinal-group is 1 so you might need to change what value to apply for it to have any effect.

Also, see this firefox-dev post for more information.

view more: next ›