Stylus: Firefox: Toggling styles is slow/non-responsive

[Keith94]

In Nightly I'm getting a delay/lag when toggling styles from within the popup. Performing the action freezes my browser for 5-10 seconds. I normally have a large amount of unloaded tabs (400+) open, but IIRC this wasn't a problem with classic Stylish.

[tophf]

Sounds like a bug in WebExtensions API, but what is an unloaded tab? Can you reproduce the issue after disabling all addons except stylus and restarting the browser?

[Keith94]

Sounds like a bug in WebExtensions API, but what is an unloaded tab?

I was referring to "Tab on demand" feature: https://wiki.mozilla.org/Tab_on_demand

Can you reproduce the issue after disabling all addons except stylus and restarting the browser?

I'll test in a clean profile and report back.

[tophf]

Also make sure multi-process is enabled in browser options. Some legacy addons thwart it.

It's also possible the tabs start loading their sites, but it's just a guess. Anyway, there's apparently no way to detect that a tab is unloaded via WebExtensions Tabs API so we can't skip them in Stylus. Running chrome.tabs.query({}, tabs => console.log(tabs.map(t=>t.status))) shows all tabs' status is "completed" which is obviously a lie.

[Mottie]

Anyway, there's apparently no way to detect that a tab is unloaded via WebExtensions Tabs API so we can't skip them in Stylus.

What about tab events? The tabs.onUpdated event fires when the status or url (and a bunch more states) of the tab changes.

[tophf]

It won't help. The problem is that the tabs have all properties set just like they would if the content is loaded.

[tophf]

Ah, wait, the unloaded tabs seem to have width set to 0. I'll try using it for a FF workaround.

[tophf]

Test version that skips tabs with zero width: ~[stylus-test.zip]~
Either test it in a separate FF installation/profile or try disabling the official Stylus and load this one on about:debugging page.

[Mottie]

Hmm, I'm getting a message stating that the manifest is invalid. I tried to load it as a temporary addon in FF Dev 55.0b2 and FF 54.0.

[tophf]

@Mottie, manifest is valid. Sorry I can't help you as I'm not that proficient with FF.

[Mottie]

Oh, duh... the files must be in the root of the zip file, not in a folder. And I got it to finally load when I switched the extension from .zip to .xpi. I'll test it now.

[tophf]

I never loaded zip directly. I always unpack it.

the files must be in the root of the zip file

Good to know, I've replaced the zip above.

[Mottie]

Firefox will only load packed files.

[tophf]

about:debugging loads unpacked extensions.

[Mottie]

Ahhh... I guess you have to point to the mainfest.json file. That's good to know too 😝

[Mottie]

I'm not exactly sure how to test this...

• I opened a bunch of new tabs.
• Opened one tab with a style.
• Reloaded all tabs.
• Toggled the styled open tab from the popup.

I didn't notice any drastic delays. The initial styling took a slightly longer time than subsequent toggling, but nothing over 1 second and no where near the 5-10 second delay reported.

[tophf]

Open 100 tabs, exit the browser, start it again, load the ~[test Stylus]~, disable the original one, import/install some big global style, toggle it. @Keith94, ping.

[ZzzZombi]

I was going to start a new thread but it's similar to this one.

After the beta channel upgrade (to FF 55) styles are not applying at all if I open a web page for the first time. Meaning if I have the same domain open at all times in any tab, style applies perfectly when I open a link on a new tab from the same domain.

Sometimes it applies to only some elements on pages sometimes it doesn't load at all until I either reload the page or disable/enable the style.

[tophf]

@ZzzZombi, I can't reproduce using FF 55 in multi-process mode. If you're running it in single-process mode, all kind of weird issues are quite expected due to the inferior architecture that is not compatible with asynchronous WebExtensions API.

[ZzzZombi]

@tophf I'm not running on multi-process, I guess I wasn't eligible for that. Is there a way to force enable it?

[tophf]

There are articles on the internet. The primary reason it may be blocked is the legacy addons.

[tophf]

~Ah, wait, I can repro in FF55 even in multi-process mode, but not in FF56 multi-process. Apparently this is just the state of WebExtensions in FF55.~

[ZzzZombi]

Thank you. I hate the FF landscape nowadays. New versions are quite fast and responsive but I have to let go of so many add-ons. Should I just ditch the legacy ones and hope that they get upgraded, should I just stick to legacy add-ons until the apocalypse(!) comes....

It's so frustrating.

[tophf]

@ZzzZombi, turns out my FF55 wasn't running in multi-process, which is why I could reproduce the issue: open about:support and look at Multiprocess Windows. In my FF55 it's 0/1 (Disabled by accessibility tools), but in FF56 it's 1/1 (Enabled by user)

[Keith94]

I installed the test version in a profile with ~400 unloaded tabs. I still experience lots of sluggishness when first loading the add-on and toggling styles on and off (even with zero styles installed)

[tophf]

I still experience lots of sluggishness

Open about:support and check what's in Multiprocess Windows. I expect 0/1, in which case this is just how bad single-process FF is.

[Keith94]

It says Multiprocess Windows 1/1 (Enabled by default). I guess the issue is something else.

[tophf]

I see no difference with 1 tab or 100 tabs (i7 4GHz here) so maybe @schomery can find a slower device. Meanwhile, try the new test version that lazifies a couple of messaging functions: ~[stylus-test2.zip]~

[Keith94]

Meanwhile, try the new test version that lazifies a couple of messaging functions: stylus-test2.zip

Performance seems more acceptable, roughly a one second delay when toggling a style in the same profile.
Opening the Stylus panel can be janky and slow at times also.

[tophf]

Well, this seems as far as I can go without being able to reproduce the issue.
The lazifying is merged in b4e00cd892e09dff9e38802c00fdd0c6b0c0568e.

Opening the Stylus panel can be janky and slow at times also.

Stylus doesn't animate the popup, this is a Firefox responsibility, so it being slow means that FF is doing it wrong. The world seems going crazy over UI animations in desktop apps once again. Chrome also animates the popup, which IMO looks amateurish and retarded so I use CentBrowser (a fork of Chrome) because it disables popup animation.

[Keith94]

Thanks for the fix! It helps a ton.

[tophf]

Oh, FF still hasn't implemented Run WebExtensions out of process feature, which explains why it blocks the UI.

[tophf]

Well, I've done what I could in the absence of proper multi-process mode in FF. When they implement it the lagging should disappear. Chrome doesn't lag.