I wonder whether this can actually happen, as that header is AFAICT added by the kernel and not from the network.

I wonder whether the getStatus handler could be cleaned up by removing the UNKNOWN value of portStatus and removing the default: case.

It doesn't seem to work here either, but adding the --print-reply argument helps for some reason.

This got implemented in https://phabricator.kde.org/D22571, which is flawed (see the various comments there).

This way the code does what it's supposed to (even though it's flawed), so definitely an improvement.

In D22571#559126, @davidedmundson wrote:

But given you're right about readlink (exe) and read(exe) behaving differently, we should be able to simplify things and have it work.

I shall do that now.

The libssh maintainer is likely reverting the change, so this should not be necessary.

LGTM. This now ignores the return value of the xft.get* calls, but that seems to be useless anyway:

That seems like just the order of assignments is wrong and more logic isn't actually needed. What about something like this:

IMO this looks uglier than multiline C macros, but ok...

In D24997#555258, @ngraham wrote:

I think we have a greater conceptual problem here. If the lock and login screens are able to display arbitrary text colors from the user's color scheme, we will never be rid of these kinds of problems. I see two practical solutions:

• Hardcode white as the text color and black as the shadow color and don't respect the color scheme

In D22571#555355, @davidedmundson wrote:

By just not faking it: LD_PRELOAD=pwn.so /usr/bin/plasmashell

Sure. But that's out of scope. We shoudln't pretend we can completely protect against unsandboxed code running as your user. You're somewhat screwed regardless.

In D24947#554005, @meven wrote:

In D24947#554001, @fvogt wrote:

IMO it's a good thing to have KRunner as application in the menu anyway

It was not in the application menu before
With this change (and without NoDisplay) it will be displayed.

IMO it's a good thing to have KRunner as application in the menu anyway

Is this not needed for <video/> as well?

Note, the "-0" option is only available in GNU env, not in BSD /env... I can't think of a better way to fix this though other than implementing env ourselves in native code.

arc is a PoS

Tried with old host, no observable change

In D24664#547710, @broulik wrote:

Since we watch the file, we will update it as neccessary once kconf_update has written it, right?

In D22210#547608, @ngraham wrote:

I thought this change was introduced with 0.18.1 though? Aren't distros with an old SDDM using something older than that?

In D22210#547602, @ngraham wrote:

FWIW to me https://github.com/sddm/sddm/pull/997 seems correct, and then we would rename the sessions upstream here. My preference would be to make the Wayland session say "Plasma (Wayland)" rather than renaming the X11 session ("Plasma on Xorg" sounds pretty awkward IMO)

See https://phabricator.kde.org/D22210 for a discussion about this.

In D24333#541012, @davidedmundson wrote:

I don't think I follow.

How does the regular non-textfield version of the login screen still work? Surely containsAllUsers will always be false.

Maybe now?

Maybe get rid of the unrelated change?

In D22210#498933, @fvogt wrote:

In D22210#498929, @asturmlechner wrote:

drop translations, rename to 'Plasma on Xorg'

That would not be symmetric to "Plasma (Wayland)" though as produced by sddm.

Unfortunately, this breaks public API and ABI by modifying KAuth::ActionReply.

Seems to work on FF ESR

AFAICT it doesn't reload the mpris state in the content-script immediately when settings change, can that be implemented?

Seems to work here

Seems a bit weird to merge it at the top-level instead of adding a new key, but it's unlikely to result in abuse.

Appears to work on ESR

Probably needs some Firefox ESR 60 testing to see whether it can deal with the class stuff...

libproxy does not link against Qt anymore, they use kreadconfig5 and friends to read the values. So using that should be safe.

Tested, works, thanks!

The same approach should probably be used for other overrides as well, like navigator.mediaSession.setActionHandler and window.Audio. That's unrelated to the bug though.

LGTM, but maybe move into a separate method instead? There's already too much in DownloadJob::update...

Works. I don't think the CSS indentation style works for data-depends-settings-value="FALSE" though, that would just be weird.

fuse.sshfs is used by kdeconnect as well, does that cause some kind of conflict?

Tested, works fine

In D23568#522065, @broulik wrote:

What we could also do which I just realized is that we could send a CustomEvent to the window instead of using postMessage
Basically what we did before except without a wrapper div as while the JavaScript contexts are different, events posted to window are visible from the content script.

Always provide a specific targetOrigin, not *, if you know where the other window's document should be located. Failing to provide a specific target discloses the data you send to any interested malicious site.

Accepting, but I REALLY don't like this as it makes the behaviour on firefox quite different compared to other browsers for no good reason.