Closed Bug 1817945 Opened 1 year ago Closed 1 year ago

[OpenBSD] failure to open links in the browser since #1714919

Categories

(Thunderbird :: Security, defect)

Thunderbird 110
Unspecified
OpenBSD
defect

Tracking

(thunderbird_esr102 unaffected)

RESOLVED FIXED
114 Branch
Tracking Status
thunderbird_esr102 --- unaffected

People

(Reporter: gaston, Assigned: gaston)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Just filing a bug as a reminder for myself.. thunderbird 102 works perfectly fine and isnt sandboxed/pledged/unveiled on OpenBSD.

Trying 110.0beta4, opening links in mails fail:

[Parent 64370, Main Thread] WARNING: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn: 'glib warning', file /usr/obj/ports/thunderbird-110.0beta4/thunderbird-110.0/toolkit/xre/nsSigHandlers.cpp:167

** (thunderbird-default:64370): WARNING **: 12:05:07.432: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn
[Parent 64370, Main Thread] WARNING: Could not launch default application for URI: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn: 'glib warning', file /usr/obj/ports/thunderbird-110.0beta4/thunderbird-110.0/toolkit/xre/nsSigHandlers.cpp:167

** (thunderbird-default:64370): WARNING **: 12:05:07.432: Could not launch default application for URI: Could not find content type for URI: https://jitsi.hivane.net/craig-ihedn

opening pdfs in the internal pdf viewer works, opening docx/ods files properly starts libreoffice.

this is most probably caused by code added in bug #1714919 to handle opening urls/files in a sandboxed firefox, but this might have the bad side effect of breaking thunderbird.

will investigate, my first guess is that g_content_type_guess in https://searchfox.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#268 fails on urls, which makes sense. I'll have a look at how glib handles non file urls...

:rstransky, sorry to bother you about that, but i've now realised my failure.

With glib/gtk, what'd be the best way to handle that ? check in g_app_info_launch_default_for_uri_openbsd that we use a file:// URI to do the content type guessing, and otherwise rely on x-scheme-handler/schema as i've seen in GetAppsForURIScheme https://searchfox.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#533 ?

Flags: needinfo?(stransky)

links clicked in thunderbird opens fine in my browser if i replace #ifdef __OpenBSD__ by #if 0 in https://searchfox.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#625 but that's obviously super gross. Just confirms the error is inside g_app_info_launch_default_for_uri_openbsd, if the g_app_info_launch_default_for_uri codepath is taken things work.

I'd say it's better to use something close to GIO if possible. You may link GIO sources for reference.

Flags: needinfo?(stransky)
Summary: failure to open links in the browser since #1714919 → [OpenBSD] failure to open links in the browser since #1714919

as i stumbled upon this again when updating my beta port from 110 to 113... :mkmelin, would it be acceptable to do this ?

@@ -622,7 +631,7 @@ static nsresult ShowURIImpl(nsIURI* aURI, const char* 
   nsAutoCString spec;
   MOZ_TRY(aURI->GetSpec(spec));
   GUniquePtr<GError> error;
-#ifdef __OpenBSD__
+#ifdef __OpenBSD__ && MOZ_BUILD_APP_IS_BROWSER
   if (!g_app_info_launch_default_for_uri_openbsd(
           spec.get(), GetLaunchContext(aXDGToken).get(),
 #else

doubt so since there arent many occurences of checks for MOZ_BUILD_APP_IS_BROWSER..

Flags: needinfo?(mkmelin+mozilla)

right now i'm also (blindly, building) testing this:

@@ -273,6 +273,9 @@ gboolean g_app_info_launch_default_for_uri_openbsd(con
     g_free(path);
     g_free(content_type);
   });
+  if (g_str_has_prefix (uri, "http://") || g_str_has_prefix(uri, "https://"))
+    return g_app_info_launch_default_for_uri(uri, context, getter_Transfers(error));
+
   if (content_type != NULL && !result_uncertain) {

but i'm not sure its wise to check the prefix of the uri, or if i should whitelist "network protocols" or instead check for "has a scheme and isnt file://"..

Martin, what do you think ?

Flags: needinfo?(stransky)

i could also use use g_strcmp against g_uri_peek_scheme(uri) if that's more glib-y. No need to free a gchar*.

That patch seems to work (at least i can go to the about widget in thunderbird and click on a link, it opens in firefox) - would love feedback before pushing that to phab. I'll backport the patch to my firefox beta builds to figure out if it has downsides, but i wouldnt know what actions in firefox would trigger this codepath.

It seems in firefox all file openings go through LaunchWithURIImpl which doesnt choke like ShowURIImpl. But the more i try to follow the codepaths that lead there the more i'm lost in searchfox.

Hints welcome so that i can properly test that im not doing it wrong !

i ended up with g_uri_parse_scheme because g_uri_peek_scheme might be too new (added in glib 2.66)

Assignee: nobody → landry
Attachment #9329573 - Flags: review?(stransky)
Flags: needinfo?(mkmelin+mozilla)

Gaston, thanks for the patch but please can you use Mercurial?
https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html
Thanks.

Flags: needinfo?(stransky) → needinfo?(landry)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #8)

Gaston, thanks for the patch but please can you use Mercurial?
https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html
Thanks.

well, i'd really like to (even if i said in my previous comment that i'd have liked feedback from you first) but moz-phab doesnt like me.

c64:~/src/m-c/ $hg log -l2
changeset:   661349:356d3a338c95
tag:         tip
user:        Landry Breuil <landry@openbsd.org>
date:        Fri Apr 21 21:43:30 2023 +0200
summary:     Bug 1817945 - repair opening links from thunderbird r=stransky

changeset:   661348:df954b717c6c
fxtree:      central
user:        Cosmin Sabou <csabou@mozilla.com>
date:        Fri Apr 21 06:04:10 2023 +0300
summary:     Backed out changeset f70225b67b76 (bug 1538043) for causing Bug 1829262. a=backout
c64:~/src/m-c/ $/home/landry/.local/bin/moz-phab submit 661349 
Failed to find any commits to submit

at that point i dont really know how to tame this tool.

Flags: needinfo?(landry)

Only affects OpenBSD-only codepaths.
Directly use g_app_info_launch_default_for_uri() if the scheme is http(s).
Regression from bug 1714919.

bah, dunno how/why but i managed to push it. Now i'd like to get rid of stray previous revisions that were already merged but hg strip wont remove them.. oh well, maybe time to switch to git ;)

o  661350:d08a2289b455 landry tip Bug 1817945 - repair opening links from thunderbird r=stransky
@  661348:df954b717c6c csabou central Backed out changeset f70225b67b76 (bug 1538043) for causing Bug 1829262. a=backout
: o  657850:c9fbcf599a37 landry Bug 1824084: use linux codepaths for BSDs in uptime-related functions
:/
o  657849:f476897a6e6a nbaumgardner Bug 1824138 - Set PiP urlbar toggle pref for PiP tests. r=pip-reviewers,mhowell
: o  657335:dc8a0e6c9e45 landry Bug 1823458 - Call StartOpenBSDSandbox after JS_Init in utility process r=gerard-majax,sefeng
:/
o  657333:c000b8aa17e1 itiel_yn8 Bug 1823523 - Improve the fix for bug 1818973 r=credential-management-reviewers,sgalich
Pushed by alissy@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/88be31223083
repair opening links from thunderbird r=stransky
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: