matrixagent

Thanks, sorry for the late response – busy week. Good point, wasn't even aware that the inherited variable view is only shown in projects but not subgroups. On a quick glance I couldn't find an existing feature proposal to add it at the subgroup level as well… but that might be because the search terms aren't terribly unique.

I'll show your demo to the team handling CI secrets, thanks again for sharing! :)

Do you have an example screenshot somewhere? I'm wondering what exactly this does that GitLab doesn't, because inherited variables are shown within GitLab UI directly – fairly barebones, though, so I'm curious to see your UI in action. (I work at GitLab, but not on this – just a big CI fan myself.)

I'm a Support Engineer at GitLab, and based on my own experience that statement is definitely correct. There's entire classes of problems you simply don't have to deal with at all for SaaS customers.

> And no, you can’t read the minds of long dead people either.

And yet that is exactly what you are doing throughout multiple comments.

Thank you, that’s another good example, to which I wish I could relate less. ;)

Thanks, that's a great example. I've actually encountered this exact thing at my current employer as well.

> All orgs should consider locking out all employees for at least one uninterrupted week a year. Very easy way to shake out all sorts of problems.

Could you give some examples?

I'm afraid that does not solve this particular problem, just happened again on the very first try. I still think this is intentional or at least happily accepted on part of Twitter, with the happy side effect to make it as shitty an experience as possible when you're not using their app.

Thanks, if that works that would be amazing. I'm most often getting it inside in-app browsers, e.g. when opening a Twitter link in Tweetbot, Apollo or similar apps. Not sure if they share the same central settings/service workers.

That's exactly what I'm planning to explore as a workaround to remove the blank pages until ABBYY and/or Apple sort this out. :)

I think you might interpret the word more harshly than I intend it to be. Something that worked before Big Sur is not working in Big Sur. It's broken. That's all there is to it for me as an end user. Of course there is a difference in reasons for things breaking, and I'm not denying that Apple might have "improved" Preview.app when you judge it by how well it adheres to a PDF spec. But it still "broke" a very common and normal workflow by doing so, and I would at least expect them to acknowledge that. If they decide breaking this is worth it, that's absolutely fine with me. But I don't think they are even aware of it, and that is not something I'm willing accept from a company with the reach and resources of Apple.

This is at least the second time that Apple breaks Preview in this way. I outlined why this bug is something a lot of users could run into, and I even mention that I'm not necessarily holding it against them that it breaks, but specifically that they don't even care to mention it breaking. After the first time, which was a big deal at the time, they should have put safeguards in place so that they could notice it happening. If the fault is with ABBYY, then I'm okay with Apple breaking it for the sake of internally improving Preview, and blame for the breakage lies with ABBYY. But I expect Apple to tell me – because it happened before. That blame lies with Apple.

That is my reasoning, and I don't think that's too high a bar for one of the richest companies on the planet, priding themselves in the details and "it just works". You don't have to agree with that, obviously. Calling me an ass for that is extremely rude and uncalled for, though. I was under the impression that this tone was actually not acceptable here.