[dark mode] clickable strings do not change color when clicked (links do not get :visited link color)
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(thunderbird_esr140 unaffected, thunderbird143 unaffected, thunderbird144+ fixed)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr140 | --- | unaffected |
| thunderbird143 | --- | unaffected |
| thunderbird144 | + | fixed |
People
(Reporter: dmccammishjr, Assigned: tobyp)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 external file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0
Steps to reproduce:
Received mail with clickable link. Clicked on link (which opened page in FF), but link did not show status change.
Actual results:
Clicked link did not show status change.
Expected results:
Clicked link should change color.
Comment 1•1 year ago
|
||
Confirmed on 144.0b1 (Linux)
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Hmm, I don't see this on Daily.
Comment 3•1 year ago
|
||
I tried to reproduce this issue using Windows 11/10, Ubuntu 24 and 25 as well as macOS 15/26 with the STR provided in the description but did not encounter this issue on 145.0a1(20250929084332), nor 144.0b3(20250930021323).
Corey, did you do anything different , or maybe used a specific hyperlink address?
Comment 4•1 year ago
•
|
||
Thanks for testing, Vlad.
I can still recreate this on the latest daily. Any visited link won't change color. I'm on Linux so maybe that's the difference. I think Magnus is on Linux too though. Although I think Doug is on Windows though so maybe not OS specific.
I also tested this morning on 144.0b2 and got the same result: links do not change color. Windows 11
Comment 6•1 year ago
|
||
Try Help | Troubleshoot mode. Perhaps you have some add-on, or userChrome.css that's preventing it from working.
Comment 7•1 year ago
|
||
It still recreates with Troubleshoot mode. I noticed this only happens in dark mode. If I toggle to light mode I see the visited links change colors.
Updated•1 year ago
|
Comment 8•1 year ago
|
||
Managed to reproduce this issue on all my devices eventually. Last good build was in 2025-08-18 and the first bad build was in 2025-08-19.
Also managed to find a regression range for this issue:
2025-10-01T11:32:59.250000: INFO : Narrowed integration regression window from [3aa733ec, c8ca4695] (3 builds) to [a2c58349, c8ca4695] (2 builds) (~1 steps left)
2025-10-01T11:32:59.260000: DEBUG : Starting merge handling...
2025-10-01T11:32:59.261000: DEBUG : Using url: https://hg.mozilla.org/comm-central/json-pushes?changeset=c8ca4695793922ef89401ff15029ea855c529db3&full=1
2025-10-01T11:32:59.262000: DEBUG : redo: attempt 1/3
2025-10-01T11:32:59.262000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/comm-central/json-pushes?changeset=c8ca4695793922ef89401ff15029ea855c529db3&full=1',), kwargs: {}, attempt #1
2025-10-01T11:32:59.264000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-10-01T11:33:00.161000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /comm-central/json-pushes?changeset=c8ca4695793922ef89401ff15029ea855c529db3&full=1 HTTP/1.1" 302 0
2025-10-01T11:33:00.785000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /comm-central/json-pushes?changeset=c8ca4695793922ef89401ff15029ea855c529db3&full=1 HTTP/1.1" 200 None
2025-10-01T11:33:00.789000: DEBUG : Found commit message:
Bug 1981696 - some adjustments after bug 1975367. r=kaie
onSendOpenPGP() was meant to never throw, as implied by the logging in the catch, which would not necssarily be reached, since we are returning the promise.
We must await the promise instead. Then the extra try/catch is not needed
Differential Revision: https://phabricator.services.mozilla.com/D260271
2025-10-01T11:33:00.789000: DEBUG : Did not find a branch, checking all integration branches
2025-10-01T11:33:00.790000: INFO : The bisection is done.
2025-10-01T11:33:00.791000: INFO : Stopped
I would suspect that the culprit is bug 1978204.
Comment 9•1 year ago
|
||
Yep, bug 1978204 seems spot on.
| Assignee | ||
Comment 10•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Comment on attachment 9517877 [details]
Bug 1989285 - Ensure visited links use correct color in dark mode. r=#thunderbird-reviewers
[Triage Comment]
Uplift Approval Request
- Please state case for uplift consideration and ensure bug severity is set: In dark mode, visited links don't change color. This is a regression in 144 and would be good to have fixed for the release.
- User impact if declined: Dark mode users won't visibly know if they've visited a link.
- Is this code covered by automated tests?: No
- Has the fix been verified in Daily?: No
- Has the fix been verified in Beta?: No
- Needs manual test from QA?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Small css change to visited links in dark mode that's already been tested locally.
- Does the fix cause any migrations to be skipped?: No
- String changes made/needed:
Comment 12•1 year ago
|
||
Comment on attachment 9517877 [details]
Bug 1989285 - Ensure visited links use correct color in dark mode. r=#thunderbird-reviewers
[Triage Comment]
Approved for beta
Comment 13•1 year ago
|
||
Pushed by toby@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/0cf403f1612b
Ensure visited links use correct color in dark mode. r=mkmelin,laurel,arschmitz
| Reporter | ||
Comment 14•1 year ago
|
||
confirm fixed win 64 eng-US
Comment 15•1 year ago
|
||
| uplift | ||
Thunderbird 144.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/dbde44b94455
Updated•1 year ago
|
| Assignee | ||
Updated•11 months ago
|
Description
•