9

I can confirm that wrapping everything in setupNightModeDetection lets Safari work again. Later when I’m not working I can try and narrow down a better fix.

Thanks again Fox!

10

next step is posting a pull request :slight_smile:

11

Ha well as I said I am not a software guy. I hang around here because I like watching people make a fool out of themselves and now I’m that guy. Wonderful…I’ll go back to lurking.

I’ve got a linux desktop and I’ve got no complaints. The iphone is through work so that’s the issue. My wife has an old macbook because…well she’s a woman and more expensive is better when you’ve got 2 x chromosomes.

Enough tangents…thanks again for the software.

12

More testing and from everything I can gather it seems Safari simply doesn’t support matchMedia event handlers, which is stupid. Still it does seem to handle the call on load; in other words, on the initial load it will honor the light/dark setting but it won’t change dynamically. I’ll submit a PR shortly after a bit more testing.

e: Source: MediaQueryList: change event - Web APIs | MDN

e2: PR: https://git.tt-rss.org/fox/tt-rss/pulls/129

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.