@Tbayer Could you provide an insight into the applied styles by inspecting the button via Developer Tools? The button should have -moz-appearance: none, color: #fff and border: 0 already applied in different selectors. It could be an issue with selector specificity, but I can't reproduce the issue on my system locally.

Here is a screenshot from "Inspect Element" on Firefox - let me know in case a different view is needed.

@Tbayer We're getting closer in identifying the issue. The applied style on other browsers rely on a CSS file that comes from a MailChimp CDN. See my screenshot. Maybe an adblocker issue, or a network issue?
I'd suggest to get rid of all those external style dependencies (bad practice anyways), although it might be harder than in other installations due to WP.org restrictions?!

The input's width is also giving us a hint, that exactly what I've described above is happening. https://cdn-images.mailchimp.com/embedcode/classic-081711.css is the CSS which doesn't get loaded.

@Tbayer @EdErhart-WMF After looking closer into the plugin administration, removing style dependency looks like a case for customer support. In the meantime I'll provide a patch set, that just duplicates the necessary styles in our stylesheet.

@Volker_E No ad blocker add-on was active. But it turns out this Mailchimp CSS is blocked by the inbuilt Tracking Protection feature that Firefox recently enabled as default in Private Browsing mode. It actually logs this in the console:

We actually already discussed this remote loading from Mailchimp as a privacy concern last year, after it had been introduced in a theme update. IIRC @ZhouZ from the Legal team said back then it was legally permissible under the blog's separate privacy policy, although we should still strive to minimize this kind of exposure of reader IPs to such third-party companies. Looks like Mozilla has similar concerns and has now taken that decision away from us, at least for part of their users ;)
Back then we already envisaged a solution like you are proposing - store the content locally - but nobody had the skills or time to implement it. So if you could do that, that would be awesome!

BTW the above log also shows that the blog attempts to load content from Twitter.com (https://platform.twitter.com/widgets.js?ver=20111117 , likewise blocked by Firefox in Private mode ), which IIRC was not the case last year and might present an additional privacy concern.

Thanks for flagging @Volker_E and helping fix this issue!

@Tbayer is right - we should avoid loading third-party resources and if we do, it hopefully will be from a company where we already have contractual privacy protections built-in (although perhaps MailChimp falls under that case if we do use them).

@Tbayer patch is at https://github.com/wikimedia/wikimediablog-wordpresscom/pull/3