When clicking a link in Thunderbird, default browser (Firefox) is lauched but stays in background window
Categories
(Thunderbird :: OS Integration, defect)
Tracking
(Not tracked)
People
(Reporter: mikeleo, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
When I click on a link, the page loads in Firefox(my default browser), but the computer stays in Thunderbird. (v69.0b2)
Actual results:
Stays in Thunderbird
Expected results:
It should have brought up the Firefox program and went to the linked page.
Comment 1•4 years ago
|
||
Firefox comes up for me when I click a link in a message using TB 69.0b2 on Ubuntu 18.04.3 LTS Linux.
I have Firefox as my default browser set in the General Firefox preferences, TB 69.0b2 as my default email application in Thunderbird's Advanced > General preferences and as the default applications in my operating systems settings.
Is that the way you are setup on Windows?
Yes. Firefox is my default browser and Thunderbird is my default mail client. I am running Windows 10. This just started happening recently.
Comment 3•4 years ago
|
||
(In reply to mikeleo from comment #2)
Yes. Firefox is my default browser and Thunderbird is my default mail client. I am running Windows 10. This just started happening recently.
That answers two of the three settings question, or I didn't understand you meant in each application and Windows 10.
Default applications in Windows 10
Settings > Apps > Default in Windows
Links bring Firefox in focus when I click a link in a message for me with TB 60.8.0 and Firefox 68.0.1 on my Windows 10 laptop.
I am also running TB 60.8.0 on my laptop and it works fine there also. Apparently something happened with the new version.
Comment 5•4 years ago
|
||
I can see that in TB 69 beta 2. I click in a link in TB, and FF launches, but the TB windows stays in top.
Alice, do you see this as well? Can you find the regression. Many thanks in advance.
![]() |
||
Comment 6•4 years ago
|
||
I can reproduce the issue. But sometimes, I cannot reproduce the issue.
This is slightly inconsistent.
Regression window(Good -> Bad(sometimes Good)):
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=166ccd934db34e30db0588952e598b410840cab6&tochange=b56bdad8ff021b74dc1c6cc64ecaf955a2f6f04f
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5b35e2ff7c15cc2f4d1eb419a18d899294560243&tochange=5805cd9ae2947386263069e1a3b2d832384bd45f
Unfortunately, there are no Win6(32) builds between the above range.
![]() |
||
Comment 7•4 years ago
|
||
s/Win6(32)/Win64(Win32)/
Comment 8•4 years ago
|
||
Thanks, Alice. BTW, some people can edit comments on BMO now to correct typos, etc. Above each of my comments I see four icons:
Edit (pen), tag, arrow (reply), minus (collapse). You don't have the edit (pen)?
As for the regression: It happened when FF switched the main windows to XHTML in
fd2b93ff0abecc11bcfbcd806262c79f5de50b9b Brendan Dahl — Bug 1550801 - Load XUL documents as XHTML documents. r=smaug
In the range there are also many other windows related changes.
Does something similar happen in FF, like "Open link in new window", is the new window always in the foreground?
Does this happen on Linux? There are a few more builds for Linux in the range given above.
Comment 9•4 years ago
|
||
Something else can could be tried: Open an Windows explorer window to a folder with an HTML document. Double-click the document. Does the FF window open in the foreground?
Updated•4 years ago
|
![]() |
||
Comment 10•4 years ago
|
||
Regression window via local build:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=166ccd934db34e30db0588952e598b410840cab6&tochange=166ccd934db34e30db0588952e598b410840cab6
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b2ae0d6b077f5fe95434913e3f6014ef7e468a55&tochange=5585edba8fdb83267722e62241952272c8e24a8f
Comment 11•4 years ago
|
||
Most likely caused by bug 1567614, also see some other regression, bug 1570845.
Updated•4 years ago
|
Reporter | ||
Comment 12•4 years ago
|
||
I noticed something new today. I'm not certain if this is 100% or not, but it seems like it is now working if the link starts with "http" and not "https"
Reporter | ||
Comment 13•4 years ago
|
||
My last theory failed today. "http" didn't work. I'll try to find a new theory.
Reporter | ||
Comment 14•4 years ago
|
||
updated to 69.0b3. No change
Reporter | ||
Comment 15•4 years ago
|
||
I tried the html file in Windows explorer and it worked the way it should. (FF came to the top)
Comment 16•4 years ago
|
||
The fix for Bug 1570845 was released as Nightly. Would anybody check the latest Thunderbird, please?
https://archive.mozilla.org/pub/thunderbird/nightly/2019/08/2019-08-26-22-40-09-comm-central/
I'll make an uplift request.
Comment 18•4 years ago
|
||
As far as I can see, this is FIXED by bug 1570845. We'll watch the backports. Thanks for the fix.
Reporter | ||
Comment 19•4 years ago
|
||
updated to 69.0b4 today. No change.
Comment 20•4 years ago
|
||
Yes, but it will be fixed in TB 70 beta and TB 68.1 ESR.
Reporter | ||
Comment 21•4 years ago
|
||
Thank you very much
Comment 22•4 years ago
|
||
Jorg K wrote:
We'll watch the backports
I for one would appreciate a backport. For I have this problem (on Linux) and I imagine that the release version of Thunderbird 70 is a long way away.
Comment 23•4 years ago
|
||
This was only ever a Windows issue and the has been backported for TB 68.1.0, I think. Not sure now, but certainly fixed in the latest version 68.2.2.
Comment 24•4 years ago
|
||
@Jork: in that case, if I find the will, I had better start a new but report.
Description
•