13

ah it probably wants legacy syntax, maybe instead of try-catch it should check whether method exists.

legacy one was addListener or something and it probably supports that one instead but we are not going to implement legacy shit because of safari.

e: it should be something like typeof mql.addEventListener etc

14

Yeah, I tried that (.addListener) during testing and it still didn’t work. :man_shrugging:

15

oh well, i’ll merge it then. thanks!

16

The other reason I like to hang around here is because you guys get shit done. It’s loading on all the mobile browsers again. Even with javascript enabled. :wink: Thanks again.

17

Much appreciated guys!

18

fwiw, this latest commit / merge from JustAMacUser fixes a no load from login issue I was having after the recent changes to tt-rss with a non-Mac browser (in both linux and windows). A browser that will go unnamed. Oh, ok, I’ll name it ==> Pale Moon (28.8.0 64-bit). Let the derision begin…

Still some sort of page loading issue when going into Preferences but a slight resizing of the browser window or minimize/unminimize the browser window or simply pressing F12 a couple of times fixes that weirdness. At least until the the next time I open Preferences. idk?
.

19

Does the console report anything?

20

Here’s a link to the output from the console while going from the tt-rss main screen to Preferences, then re-sizing the browser window to get the re-drawing right and then exiting Preferences again. I’m clueless as to whether any of the output is relevant?

btw, I typed before that minimize/unminimize the browser window got the Preferences screen to look right. Wrong! Slightly re-sizing the browser window or F12 (or F11) twice is what works every time.

Here’s a screenshot of what I see when first entering Preferences (Pale Moon --safe-mode)

broken_prefs_view0
broken_prefs_view01222×789 51.9 KB

.

.

21

when you’re using a placebo-tier fork of a really ancient firefox code made and “maintained” by a creepy furry, things not working quite right should be expected behavior.

i literally can’t think of a single legitimate reason to use any of those clones, i.e. waterfox, pale moon, whatever else.

22

In case anyone in the future wants to debug a Safari issue without having an Apple device, you can use GNOME Web (aka Epiphany). It uses the same WebKit as Safari with pretty much the same bugs and missing functionality.

Incidentally, I think line 595 of tt-rss.js is wrong. It catches the failure to initialize App and then uses App. I hate window.alert as much as the next web dev, but I think it might be appropriate here instead of getting stuck on “Loading, please wait”?

23

e: maybe this could call AppBase instead? nope. it’s the alert then.

also,

thanks for the information but i can’t really imagine myself installing gnome to debug issues in safari. this has wrong direction written all over it.

24

FWIW, that last error that @martywd reported on Pale Moon also happens to me on Firefox 71.0 (64bit) (latest release on Win10). Simply resizing the window by opening the dev console fixes it. Sorry for hijacking this thread further.

25

I see the same thing on Firefox 71.0 64-bit on macOS 10.15.1, too.

26

Damn! Just checked firefox 71 (which I rarely use) on a windows 7 machine. Same issue as I reported w/ Pale Moon and now that @f0ff886f and @AngryChris type about.

fwiw,here’s a link to conole output from firefox 71 (64-bit) in safe mode on the windows machine. The console output is from tt-rss login screen on firefox, to main screen , to Preferences, F11 press twice to get the screen tab to redraw properly, and then exit Preferences.
.

27

so is this related to night mode or something? can you bisect?

if its not related this issue should probably be in its own thread.

28

I’m seeing this on Firefox 68.3.0 ESR in Debian Buster.

This was definitely not a problem as recent as last week. I don’t go into Preferences often (which is why I didn’t notice sooner) but I have been in there in the last week so it’s for sure a recent commit. I don’t have time to troubleshoot at the moment.

A quick look in the inspector seems to suggest that div containers inside #main are being set with a height that’s too short (57px in my case) so the content doesn’t appear. Resizing anything triggers Dojo to recalculate the layout and set the proper size.

29

Just ran bisect. Yeah, it’s commit 0237dee980157554ab2c9a79b6e9d10cec9e2f3a (implement automatic night mode detection using MQL)

30

it’s likely a race condition between dojo initializing and css stylesheet being replaced by nigh mode detection, chrome is either faster or smarter at this so it’s not visible there.

going by this post

this sounds like dojo displayed without css.

31

well, apparently this happens because firefox has an asynchronous loader for CSS, while blink-based browsers block on CSS load. so, on startup, dojo gets confused because execution continues while CSS is still reloading because of day/night change.

it’s kinda sad, while not surpising, that what started as a 10 LOC quality of life patch turned into a huge ugly monstrosity.

https://git.tt-rss.org/fox/tt-rss/commit/07f4878d59a7459472e66a2ba0c1c0413232107e

32

Works here. Thanks for the update.