Twitter "report user" popup-webform background is white, if you get their "Lights Out" theme automatically via your browser-reported dark-mode preference
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
Attachments
(2 files)
screenshot (Firefox on left, Chrome on right)
[NOTE: I'm updating this comment for clarity after diagnosing the issue in comment 3-4]
STR:
- Clear all cookies for twitter.
- Set your browser to have a dark-mode preference for web content (or set that preference in your OS)
- Visit https://twitter.com (confirm that the landing page looks dark -- it should, if step 2 was successful) and sign in.
- Visit the page for some twitter user, e.g. https://twitter.com/mozilla
- Click the 3-dot menu just below the user's banner-image and choose "Report @<user>"
ACTUAL RESULTS:
The popup form that appears ("Help us understand the problem. What issue with @<user> are you reporting?") has a bright white background, despite the fact that I'm using a dark theme on Twitter. (It's actually got a dark top and bottom section and a bright-white content area.)
EXPECTED RESULTS:
The popup form should have a dark background.
All browsers give ACTUAL RESULTS if I follow the above STR. (I tested Firefox, Chrome, and Safari on macOS.)
All browsers give EXPECTED RESULTS if I take the additional step of visiting https://twitter.com/settings/display and clicking back and forth between the various themes (and ending up on a dark theme). This seems to be necessary (i.e. you have to explicitly select one of the themes) in order for Twitter to add night_mode=2 to your document.cookie value; and that night_mode value seems to be necessary in order for the "Report User" UI to show a dark background color.
|
Assignee | |
Comment 1•2 years ago
|
||
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 2•2 years ago
|
||
This is an iframe, but this isn't really iframe-specific. If I load the iframe src as a top-level document in Firefox and Chrome, I see the same issue.
e.g. simpler STR are to just directly go this URL (which is the URL inside the iframe, with some params removed):
https://twitter.com/i/safety/report_story?source=reportprofile&reported_user_id=106682853
(Please don't click through the whole process to actually report the Mozilla twitter account. :))
For me, in Firefox, this page renders white, whereas in Chrome it renders as dark gray.
This seems to be because we're receiving (or ending up with) different content. DevTools shows that Firefox gets
<body class="ResponsiveLayout">
...whereas Chrome gets:
<body class="ResponsiveLayout ResponsiveLayout--Night">
If I add ResponsiveLayout--Night to the body element's class list in Firefox (i.e. rendering the same content as Chrome), then we get the same dark rendering.
|
|
Assignee | |
Comment 3•2 years ago
|
||
This difference in the body markup is present in the raw HTML that's returned from our GET request. (The class isn't dynamically built using JS or anything like that.)
i.e. if I open network devtools and pick "copy as cURL" in Firefox and in Chrome for the main request, I can see the class attribute differing in the response, matching the values in comment 2.
Looking closer at the "copy as cURL" commands, the relevant difference is in some bonus data in the -H 'Cookie: header that gets sent in Chrome. The Chrome request has night_mode=2 as one of the semicolon-separated-values in that Cookie header, vs. the Firefox request does not. And indeed, if I look at document.cookie in devtools in Chrome vs. Firefox, I see that value present in Chrome vs. not in Firefox.
So this is just a case where Twitter seems to be including night_mode=2 as part of the cookie for Chrome users but not for Firefox users, for some reason...
|
|
Assignee | |
Comment 4•2 years ago
|
||
OK, I've gotten to the bottom of this issue and it turns out I was slightly off in my STR. :)
Specifically this step was wrong, and I'll edit my STR to correct it:
- Visit https://twitter.com/settings/display and choose "Lights Out" as your theme.
If you actually manually do this (change themes back and forth here), then Twitter adds night_mode=[0,1,2] to `document.cookie (0 = light, 1 = dim, 2 = lights-out). And that gets you EXPECTED RESULTS here as described above.
BUT: in Firefox on my system (with a dark OS theme which Firefox reflects in prefers-color-scheme by default), Twitter sees my dark mode preference and just uses their Lights Out theme by default; BUT they do not set the night_mode cookie component by default until/unless you actually visit https://twitter.com/settings/display and make a selection. So if you just use Firefox in dark mode and get Twitter's dark mode look automatically (rather than having to explicitly opt in via their settings UI), then this component of your cookie is unset, and so you'll get the default light-mode rendering of the "report user" flow.
So: this is a site bug in Twitter, and it's reproducible on all browsers that allow you to express a "dark mode" preference (whether directly or via the OS settings). Chrome on Linux happens to not let you express dark-mode preference AFAICT, which is why I wasn't seeing this there.
I've reproduced the issue in Chrome-on-macOS and in Safari-on-macOS, with macOS system settings configured to use dark mode by default.
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 5•2 years ago
|
||
I reached out to the mozilla/twitter discussion list to give them a heads-up about this issue.
|
||
Comment 6•2 years ago
|
||
I was not able to reproduce this issue on the latest Nightly. Daniel, can you please take a look and give us an update?
Tested on:
Operating system: Windows 10
Browser/Version: Firefox Nightly 111.0a1 (2023-01-31) / Firefox Release 109.0.1
|
|
Assignee | |
Comment 7•2 years ago
|
||
Yeah, I can't reproduce this anymore either, following STR in comment 0. Back in September, I did get a response from the twitter folks in response to the outreach that I mentioned in comment 5, and they confirmed the issue and said that a fix was on the way at that point. Seems like it was indeed fixed.
Thanks!
|
|
Assignee | |
Updated•2 years ago
|
Description
•