perma comm/mail/test/browser/content-tabs/browser_aboutSupport.js | String "undefined" should not be on the content tab's page - false == true
Categories
(Thunderbird :: Upstream Synchronization, defect, P5)
Tracking
(thunderbird_esr115 unaffected)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr115 | --- | unaffected |
People
(Reporter: intermittent-bug-filer, Assigned: mkmelin)
References
Details
(Keywords: intermittent-failure, intermittent-testcase)
Attachments
(3 files)
Filed by: mkmelin [at] iki.fi
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=446085861&repo=comm-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NR3Xq0R8QT2EwAVdmA9z3A/runs/0/artifacts/public/logs/live_backing.log
New failure. Probably something needs porting
| Assignee | ||
Comment 1•2 years ago
|
||
| Assignee | ||
Comment 2•2 years ago
|
||
Confirmed by local backout this is from bug 1826412. Specifically https://hg.mozilla.org/mozilla-central/rev/a5f0b8602ce1
I don't understand why.
Adding https://hg.mozilla.org/mozilla-central/diff/a5f0b8602ce17980ab43e5e46e7bff4f4bf6a844/toolkit/content/aboutSupport.js to mail/components/about-support/content/aboutSupport.js doesn't help, though it should probably be done.
| Assignee | ||
Comment 3•2 years ago
|
||
Maybe Thunderbird builds are missing some ifdef for something. xref bug 1877660.
Tom, any ideas of what might be missing?
Comment 4•2 years ago
|
||
I'm sorry, I am not terribly familiar with these bits. My best guesses to trial/error would be:
It looks like it's saying "Undefined" shouldn't appear anywhere on about:support, but now it is". Does opening about:support on Thunderbird Nightly show you where it's saying "undefined"? Presumably in the new field I added - "Font Visibility Debug Info"
Prehaps the code I added in nsIGfxBase needs additional ifdefs/cases for Thunderbird, so it doesn't show up as undefined?
| Assignee | ||
Comment 5•2 years ago
|
||
Screenshot
| Assignee | ||
Comment 6•2 years ago
|
||
I would think it's not the test that is wrong, but showing a real issue (of some sort, like is gpu detection not working due to some ifdef?).
Comment 7•2 years ago
|
||
That patch (mine) doesn't do anything to GPU detection... If backout is showing that https://hg.mozilla.org/mozilla-central/rev/a5f0b8602ce1 is the source of the issue, I would try isolating it further. Specifically, does removing the row I added to the about:support page fix things?
| Assignee | ||
Comment 8•2 years ago
|
||
Unfortunately that doesn't help.
But your suggestion made me explore this a bit more. This is the offending line: https://hg.mozilla.org/mozilla-central/rev/a5f0b8602ce1#l5.12 - if i remove it things are fine. The very odd thing here is that prop by itself is not a problem...
I found a "fix". It looks like something is only available properly on 2nd/3rd access.
| Assignee | ||
Comment 9•2 years ago
|
||
Comment 11•2 years ago
|
||
No, I don't know why that would happen... (Although I'm far from experienced in XPCOM.) Maybe if there was multi-threaded access...? Although I don't think that's happening here. The relevant code is all here...
You could try doing something simpler in GetFontVisibilityDeterminationStr, like copying how GetContentBackend(nsAString& aContentBackend) just assigns a string, and seeing if that changes the behavior...
Comment 12•2 years ago
|
||
I think this line should be fontVisibilityDeterminationStr: "supportFontDetermination", since the L10n string is called support-font-determination not font-determination. That fixes the test.
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
| bugherder | ||
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Comment 17•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/970b0125b6a7
Port bug 1826412: add supportFontDetermination to about:support. r=freaktechnik
Description
•