Feature request: CSS delayed second run-at

[tmcomm]

Issue Description

Many sites are still loading/changing CSS after @run-at document_idle. One widely used example of this is YouTube, which I frequently need to manually re-run the UserCSS in order for all of the styling to be correctly applied.

Re-running the UserCSS requires a few mouse clicks and selecting the UserCSS from a list. Sometimes it's easier to just refresh the page a few times until it works.

Feature Request

Add a new @run-at that can can be used in addition to document_idle to re-apply the UserCSS at X seconds after document_idle.

I had a few ideas about how this could be accomplished from a user perspective, but I'm not sure about the feasibility of any of them:

• A new @run-at such as idle_plus that would run the UserCSS at document_idle and at a delay specified in @run-at-delay
• If adding @run-at-delay is problematic, a few new @run-at options such as idle_plus_1s, idle_plus_3s, and idle_plus_5s could be added instead
• @run-at could remain unchanged, and @run-at-delay could re-run the the UserCSS independently of the @run-at being used

Alternate Feature Request

The feature above would be preferred, but making it easier to manually re-run the UserCSS would still be an improvement. Here are some ideas:

• A toolbar button to re-run any active UserCSS for the page
• If an additional toolbar button is problematic, a button at the top of the toolbar menu to re-run all UserCSS without having to select from the list would be an improvement.

Thanks!

[erosman]

A new @run-at such as idle_plus that would run the UserCSS at document_idle and at a delay specified in @run-at-delay

Browser APIs only support 3 states for run_at . They don’t have a method to apply a delay or re-run.

A toolbar button to re-run any active UserCSS for the page

Extensions can only have one toolbar button.

If an additional toolbar button is problematic, a button at the top of the toolbar menu to re-run all UserCSS without having to select from the list would be an improvement.

Re-applying all scripts/CSS just for one is inefficient.

Suggestions

• In case there are conflicting CSS rules, adding !important can increase the rule's priority.
  Add cssOrigin to declarative contentScripts API may help but it was only added in Firefox 144.

• A userScript can also have a delay and re-run the code if needed. However, a userScript can get blocked by a site's CSP.

STR

If you provide a minimal STR, I will see if there is a good solution.

[tmcomm]

Re-applying all scripts/CSS just for one is inefficient.

I was thinking of a separate button for CSS only, but I agree it's still inefficient.

Add cssOrigin to declarative contentScripts API may help but it was only added in Firefox 144.

That's good to know, thanks. I'll update to Firefox 144 and try it out.

If you provide a minimal STR, I will see if there is a good solution.

I'm sorry, I'm not familiar with the STR acronym. My only UserCSS's with this issue use the new :has selector, but that's probably coincidence. I'll need to inspect the pages closer when it fails to see what exactly is changing after the UserCSS is injected. I do know that rules with !important are affected, but it could still be rule priority issues.

UserScript Question

I would prefer to avoid using UserScripts when only making CSS changes, but it sounds like that may not be possible, or worth the effort, in cases like this.

Is it possible to have a UserScript inject a UserCSS? That would be really nice to keep the UserScript as minimal as possible. I didn't see anything related to this in the documentation, but I could have missed it.

[erosman]

That's good to know, thanks. I'll update to Firefox 144 and try it out.

It is an API feature, not accessible to users.

I'm not familiar with the STR acronym

Steps to Reproduce

I would prefer to avoid using UserScripts when only making CSS changes, but it sounds like that may not be possible, or worth the effort, in cases like this.

A userCSS is more performant and its effects last during JavaScript changes to the page.
UserCSS is still the best option.

A userScript only gives you the option to add a timer to re-insert.

Is it possible to have a UserScript inject a UserCSS?

A userScript can inject normal CSS using GM.addStyle or GM_addStyle.
A userScript can also @require a userCSS but that will be injected automatically and there wont by a chance to re-inject it.

[tmcomm]

Steps to Reproduce

It happens most often with YouTube, but it's hard to reliably reproduce and seems to be related to the state of their server. It won't happen for a few days, then it will happen on maybe 30% of page reloads for an hour or so.

@run-at           document-idle

ytd-rich-grid-renderer {
  --ytd-rich-grid-items-per-row: 5 !important;
}

The above UserCSS is where I see the issue the most often. It has ~10 different selectors. All of them except the one above hide elements with display: none !important.

Unless there is something obvious I could be doing differently, I wouldn't waste your time trying to fix my specific issue that I don't think is caused by firemonkey.

UserScript injection of UserCSS

A userScript can inject normal CSS using GM.addStyle or GM_addStyle.

I was asking, more specifically, if a UserScript could inject a UserCSS that was saved in firemonkey. Something like GM_addStyle(name-of-userCSS);.

That would be nice so that a UserCSS could be used generally, and a script could basically do nothing but reload it after a delay, or check the current state and reload it if needed. Without this, I think I would need to either have an unwanted delay and only load the CSS from the script, or keep the same CSS updated in both a UserCSS and a UserScript.

I could potentially see this functionality being useful too for dynamically changing between multiple different styles with the ability to enable one of them to efficiently load at the start without the script.

[erosman]

@run-at document-idle

Generally, it should not be an issue. A style injected at document-start would work for the tab until it refreshes or navigates.
The only time it becomes an issue is when another style rule overrides it.
You can check the Developer Tools to see what is affecting the target element.
That is why an STR, which would be a minimal userCSS and a URL to test it on, is needed to check it.

I was asking, more specifically, if a UserScript could inject a UserCSS that was saved in firemonkey. Something like GM_addStyle(name-of-userCSS);.

There is no such feature currently.

[tmcomm]

Thanks for the help. I'll try to figure it out on my own and send an STR if I still have issues.

[erosman]

Another idea would be ...

• Create a duplicate userCSS
• Leave the original to run at default document-start
• Set the duplicate to run at document-idle

[tmcomm]

Another idea would be ...

* Create a duplicate userCSS

* Leave the original to run at default `document-start`

* Set the duplicate to run at `document-idle`

I'll try this and see if it's any different than just using document-idle.

Here's a minimal STR, but the issue is very sporadic so it's hard to test:

/*
==UserCSS==
@name             test-youtube
@match            https://www.youtube.com/
@version          1.0
@run-at           document-idle
==/UserCSS==
*/

/* Set number of thumbnails per row to 5 */
ytd-rich-grid-renderer {
  --ytd-rich-grid-items-per-row: 5 !important;
}

Now I'm not sure if things changing after @run-at is even causing the issue. Normally I can see the userCSS style sheet in the browser's Style Editor. When the issue occurs and the changes in the minimal STR above don't happen, the style sheet isn't even there in the Style Editor.

Am I correct in thinking that things changing in the page later shouldn't ever remove the injected style sheet altogether?

[erosman]

Am I correct in thinking that things changing in the page later shouldn't ever remove the injected style sheet altogether?

That is correct.

I tested your userCSS without @run-at document-idle and it seems to be working.