10

From doing a bit of research, it seems that the function TTRSS is complaining about is “experimental technology” that is not widely supported. Firefox 55+, Chrome 47+, and Opera 34+ can handle it, but earlier versions, and other browsers, cannot.

I wouldn’t call SeaMonkey a luddite browser (Firefox was essentially forked from it, and in spite of Mozilla’s indifference the two browsers still share a common code base and some developers and development infrastructure) but the latest version is lagging behind the browser engine core. I guess I’ll just revert to an earlier version of Tiny Tiny RSS while I wait for the next browser upgrade.

11

it’s not even about this particular method of window object, adding a workaround for it would be a one line source change.

what this is about is establishing some platform requirements for the frontend, because taking into account garbage like safari not having anything implemented or working properly, ever, is tiresome.

people don’t expect me to maintain compatibility with someones ancient piece of shit server running PHP 4.0, forever. in exactly same fashion i’m not going to support web browsers feature-stuck in the last century, indefinitely, because of people who just can’t move on.

oh you don’t say

(released 2017)

(released 2015)

i’m sorry your dead progenitor of firefox couldn’t merge an ‘experimental technology’ that was implemented everywhere else that matters years ago.

i suggest checking out something from 2015, installed on a debian squeeze server, to be period accurate with your browser.

this was a nice release, i think: https://git.tt-rss.org/fox/tt-rss/src/1.15.3

12

So am I, but I’m willing to put up with some delay in implementing features in order to avoid having to use Firefox’s Fisher-Price interface. I think you know, though, that cherry-picking individual features to merge isn’t always practical. The browser core is a separate module shared by Firefox, Thunderbird, and SeaMonkey, and it gets upgraded as a unit. Recent (well, 2017-ish) changes broke compatibility with the front ends and add-on APIs, and when Mozilla cut funding, the latter two projects haven’t been able to keep up on the development work. (Previously, the three applications were usually able to maintain near-simultaneous feature parity.) The work is still happening but it’s taking a while.

Anyway, none of this should be construed as a demand for you to provide a workaround. You set whatever platform requirements you’re willing to support. If my system doesn’t meet the requirements, I’m willing to wait until it does.

13

well since you were being so civil about it i went through the other newer stuff that tt-rss is using and it seems that indeed this idle thing is a sole outlier, therefore in this particular case adding a hard dependency on it seems like going a bit too far. therefore, it is no more.

i guess ES 2015 remains the biggest requirement for now.

e: well at least i got an excuse to shitpost a bit, which is never a bad thing

14

:cry:

:sunglasses:

(Though in truth I’ve been migrating away from Apple since their stuff has gotten even more overpriced than what it used to be.)

15

yeah i guess ultimately this wasn’t the hill to die on :shrug:

16

it seems that indeed this idle thing is a sole outlier, therefore in this particular case adding a hard dependency on it seems like going a bit too far. therefore, it is no more.

Oh, thanks for reconsidering the matter.

at least i got an excuse to shitpost a bit

Having read these forums for a while, I’ve become inured to it (as a spectator, anyway).

17

Just a heads-up guys — the latest commit will mean incompatibility for Safari browsers on both macOS and iOS (in fact this affects all browsers on iOS as all of them use webkit). It throws out the following error:

requestIdleCallback error

Not sure if @fox would re-consider not making it a hard dependency like he did back in Dec 2018, but all other browsers (I’ve tested Edge, FF and Brave) on macOS would work just fine. Just SOL for iOS though.

18

they still haven’t implemented it? what’s wrong with apple.

anyway, we already have global css override, maybe it’s a good idea to add a similar thing for js, so that people could add their polyfills or whatever globally.

19

https://git.tt-rss.org/fox/tt-rss/commit/27ab16b6dc649fbda0ee329b42f1882623f9cba6

e: i haven’t checked but if link is not enough for polyfills script could be embedded.

20

They don’t care how things work, as long as the marketing is good.

Anyway, I don’t have an Apple device near me at the moment, but I think this is available as an experimental feature in Safari. On an iPad/iPhone: Settings > Safari > Advanced > Experimental Features. Toggle requestIdleCallback on. While you’re there, toggle Lazy Image Loading on, too.

21

:laughing: I know right? Apple is so behind the curve when it comes modern browser technologies. But I use it on my Mac as it gives me the best battery life.

Thanks @JustAMacUser, toggling ‘requestIdleCallback’ on solves it for Safari on iOS. The same can be done for Safari on macOS; first enable the Develop menu in Preferences > Advanced tab. Then in Develop menu > Experimental Features > requestIdleCallback (just click to ensure there’s a checkmark next to the item).

22

BTW i get this error (window.requestIdleCallback` not found) on Chrome browser 87.0.4280.77 on ios 14.4.
In Safari it works after enabling experimental features, but not in Chrome.

23

ITT: apple user learns that chrome on his shitty platform is actually a wrapper over safari

but at least you got both apple and google spying on you while you use it

24

Since updating today browser checking isn’t working anymore under macOS / Safari Version 14.0.3 (16610.4.3.1.7)

From https://git.tt-rss.org/fox/tt-rss
 * branch                master     -> FETCH_HEAD
   9b321be27..1664b8782  master     -> origin/master
Updating 9b321be27..1664b8782

Error: Browser check failed: window.requestIdleCallback not found.

Stack Trace:
https://URL/js/App.js?1615822050:694:28
forEach@[native code]
checkBrowserFeatures@https://URL/js/App.js?1615822050:691:58
https://URL/js/App.js?1615822050:665:40
https://URL/js/App.js?1615822050:189:16

Thanks

25

Please search before posting. This was addressed recently here.

26

To ‘just make it work’ on a server:

  1. Create themes-local/local-overrides.js
  2. Put a content of https://github.com/pladaria/requestidlecallback-polyfill/blob/master/index.js there (a polyfill for this property).
  3. Done.
27

This is not related specifically to TT-RSS, but enabling the requestIdleCallback experimental feature in Safari seems to break logging in to Google (at least in iOS/iPadOS; I can’t test macOS). After entering your username Google’s login page will sit there indefinitely. Disabling requestIdleCallback resolves the issue.

If you encounter this issue and need both Google and TT-RSS to work, using the polyfill above is probably a better course of action.

Related: https://discussions.apple.com/thread/251961072?answerId=253815986022#253815986022

28

Had this catch 22.

Can confirm that proposed work-around works on macOS with the fix of typo: The directory is called themes.local

29

Is there a way to access this or implement this change with the docker-compose install? I’m just migrating from a hosted install and can’t see where implementing this is an option.